Подтвердить что ты не робот

Производительность BIGINT mysql по сравнению с INT

Я пытаюсь выяснить, станет ли моя таблица менее результативной, если я изменю первичный ключ на BIGINT (20). На данный момент я использую INT (7) и имею 300.000 записей уже с большими идентификаторами (7 или 8 цифр). Я много искал, но только узнал, что он использует больше дискового пространства (что очевидно).

Все мои идентификаторы имеют 7 цифр прямо сейчас, но мой клиент хочет изменить на 8 цифр. Я не буду в состоянии легко менять программное обеспечение в будущем, поэтому я подумал об использовании BIGINT (20) сейчас на всякий случай. Было бы хуже, если я использую BIGINT, хотя мне еще не нужно?

Кто-нибудь, у кого есть опыт, имеет предложения относительно скорости и производительности?

4b9b3361

ОТВЕТЫ

Ответ 1

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

При этом производительность не имеет значения. Зачем? Потому что, когда вы достигаете точки, где вы переполняете INT, BIGINT является единственным решением, и вам придется с этим жить. Кроме того, в этот момент (учитывая, что вы используете PK с автоматическим инкрементом, у вас будет более 4 миллиардов строк), у вас будут большие проблемы с производительностью, и издержки BIGINT по сравнению с INT будут наименьшей из ваших проблем.,

Итак, рассмотрим следующие моменты:

  • Используйте UNSIGNED, если вам не нужны отрицательные значения, это удвоит лимит.
  • Максимальное значение UNSIGNED INT составляет 4,294,967,295. Если вы используете PK с автоматическим приращением, и у вас есть только 300 000 записей, вам действительно не о чем беспокоиться. Вы даже можете использовать MEDIUMINT на данный момент, если только вы не планируете действительно очень быстрый рост. (см. http://dev.mysql.com/doc/refman/5.1/en/integer-types.html)
  • Число в скобках после типа не влияет на максимальное значение типа. INT (7) совпадает с INT (8) или INT (32). Он используется для указания ширины дисплея, если вы укажете ZEROFILL (см http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html)

Ответ 2

Не желая воскрешать зомби, но "современный" mysql использует тип столбца serial, который представляет собой bigint (20) unsigned NOT NULL AUTO_INCREMENT - и, безусловно, предполагает, что mysql будет (или будет) оптимизирован для использования bigint в качестве первичный ключ.

Кроме того, вместо использования serial, первичная система bigint позволяет одному (мы делаем это) использовать uuid_short() для первичного ключа (не uuid - который очень медленно использовать в качестве первичного, потому что это строка) - который имеет функцию обеспечения того, чтобы у каждой записи был ключ, уникальный для всей базы данных (в действительности - для сети).

Но имейте в виду - некоторые принуждения ухудшают bigint до int с плохими результатами. Например, если вы сравниваете строковое представление с большим целым числом - вы можете обнаружить, что получаете ложные срабатывания. Так что нужно сравнивать, используя двоичный файл... например,

where id = binary id_str

Лично я бы назвал это нефиксированной ошибкой...