Mysql PK и FK char (36) против int (10) - PullRequest
Новая
       37

Mysql PK и FK char (36) против int (10)

2 голосов
/ 23 февраля 2011

Я читал, что mysql может обрабатывать индексы и выполнять поиск лучше, если ключи таблиц являются целыми числами, а не char (36) UUID.

Стоит ли конвертировать в int (10)?

ПРИМЕЧАНИЕ. Мы используем только 1 сервер, и в настоящее время нам приходится планировать одновременное использование нескольких баз данных, что устраняет одну из основных причин использования UUID. Наши таблицы также InnoDB, если это имеет значение.

Заранее спасибо.

Ответы [ 3 ]

2 голосов
/ 23 февраля 2011

Обычно СУБД может обрабатывать целочисленные ключи как PK более эффективно, чем другие типы данных.Причина в том, как он строит индекс для столбца, поэтому да: если вам не требуются строковые (или другие типизированные) ключи, вы всегда должны использовать целые числа.

Однако:CHAR (36) и INT (10) далеки от того, чтобы быть равными, потому что INT (10) на намного меньше, чем CHAR (36).Я не знаю, если вам нужно так много разных ключей, но вы должны помнить об этом.

Обновите, чтобы завершить последний абзац: INT(10) это 32-битный, CHAR(36) это 36 - ^ байт^ (= 288 бит).Это не только означает, что INT занимает меньше места, но и означает, что CHAR(36) имеет примерно в 4 раза больше разных ключей.

1 голос
/ 23 февраля 2011

InnoDB имеет огромное значение.Если вы определяете PRIMARY KEY для своих таблиц, InnoDB использует его в качестве кластеризованного индекса.

Операции DML с огромными таблицами innodb очень дороги.Если у вас много объединений, используйте целые числа.Если у вас много dml, используйте int.Если у вас гораздо больше вариантов, чем в dml, используйте естественные ключи, независимо от типа int или char

1 голос
/ 23 февраля 2011

UUID - это уже проиндексированная строка, но, как всем известно, символьные клавиши медленнее, чем числовые клавиши, потому что размер индекса.

Но если вам нужен UUID или символьное соединение / индекс, вы должны принять этоУчтите:

  1. Клавиши CHAR действительно медленнее для объединений по сравнению с целочисленными клавишами
  2. Ухудшение производительности может варьироваться от нескольких процентов до пары раз для таблиц Innodb
  3. MyISAMТаблицы могут значительно пострадать, если сжатие ключей не отключено.
  4. Объединение с более короткими ключами CHAR значительно быстрее, чем с длинными ключами
  5. Latin1 (я полагаю, любая простая кодировка) значительно быстрее для объединений по сравнению с UTF8

Я делюсь этой информацией и проверил ее в производственной среде, ее можно найти в http://forums.mysql.com/read.php?24,263462,263462

...