MySQL: размер VARCHAR как PK так же быстро, как INT? - PullRequest
1 голос
/ 10 августа 2011

Какова будет хорошая / безопасная максимальная длина для столбца VARCHAR, поскольку первичный ключ не намного / медленнее, чем INTEGER ID, использующий MySQL 5 + InnoDB в 64-битной системе ? Обратите внимание, что предполагается, что на этот PK ссылаются другие таблицы, поэтому он появится в ряде JOIN.

Будет ли VARCHAR (7) хорошей длины? 6? 8? 10? Больше? Меньше? Почему?

Может быть трудно ответить, но должен быть хотя бы верхний предел, основанный на фактах, например основанный на внутренней работе MySQL / InnoDB ( структуры индекса , ...?).

Редактировать: предполагать кодировку символов ASCII с учетом регистра.

Ответы [ 3 ]

3 голосов
/ 10 августа 2011

Использование поля int обычно предпочтительнее для ключей.Два числа можно сравнить в одной инструкции на ассемблере практически на любой существующей платформе.Сравнение двух строк неизменно требует предварительного цикла и дополнительных шагов настройки или нескольких циклов процессора, даже если в процессор встроены инструкции сравнения строк.

2 голосов
/ 11 августа 2011

Какова будет хорошая / безопасная максимальная длина для столбца VARCHAR как первичный ключ не намного / медленнее, чем INTEGER ID при использовании MySQL 5 + InnoDB в 64-битной системе? Обратите внимание, что этот ПК следует считать ссылаться на другие таблицы, поэтому он появится в ряде JOIN.

Не намного медленнее делать что? ВЫБРАТЬ? ОБНОВИТЬ? ВСТАВИТЬ? Мои внутренние пользователи хотят более быстрые вставки; мои пользователи хотят быстрее выбирать.

Частично производительность (что бы это ни значило) зависит от вашей конкретной структуры базы данных, ваших конкретных шаблонов запросов и вашего конкретного серверного оборудования. Что показали ваши собственные тесты?

Может быть трудно ответить, но должен быть хотя бы верхний ограничение на основе фактов, например основанный на внутренней работе MySQL / InnoDB (индексные структуры, ...?).

Если бы был верхний предел, вы бы не могли рассчитывать на то, что он останется неизменным даже при незначительных обновлениях версий. И, конечно же, оптимизатор запросов принимает решения во время выполнения, а не во время разработки. Принятие долгосрочных решений по проектированию баз данных на внутренних элементах dbms в том виде, в котором они существуют сегодня , не является наилучшей практикой. (Это просто наблюдение. Я не намекаю, что это то, что вы делаете , но многие люди, которые читают это, могут сделать именно это.)

Если вы хотите знать, как работает определенный набор таблиц, имеет смысл отредактировать ваш вопрос и включить DDL. Таким образом, мы по крайней мере говорим об одном и том же. Как и сейчас, каждый, кто отвечает, вероятно, будет использовать другую структуру. (Если они вообще потрудятся проверить.) И мы можем не раскрывать наши личные - а иногда и необоснованные - предположения.

В одном конкретном случае - из другого вопроса SO - использование идентификаторов и соединений заняло в 100 раз больше времени, чем использование естественного ключа. (32-битный PostgreSQL.) Таким образом, люди могут целый день говорить о том, сколько инструкций ЦП требуется для сравнения целых чисел или строк, или количества байтов в целом числе, или количества байтов в сопоставлениях UTF-8, или чего-либо еще. Тем не менее, в этом конкретном случае VARCHAR (30) выиграл в результате оползня.

Когда я был в армии, у нас была поговорка. «Когда ваша карта и местность не совпадают, следуйте по местности».

Если теория и измерения не согласны, выполните измерения. Разработайте правила большого пальца из измерений.

2 голосов
/ 10 августа 2011

Все, что больше, чем VARCHAR (4) в кодировке ASCII (и сопоставление ascii_bin - вам не нужно сопоставление без учета регистра для реляционных операций), будет медленнее, чем INT (поскольку INT имеет длину 4 байта)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...