В базе данных, почему первичный ключ не должен быть слишком длинным?

база данных MySQL

Продолжайте отвечать на вопросы планетарных друзей воды:

_Г-н Шен, я слышал из Интернета, что таблица данных MySQL, в случае большого количества данных, первичный ключ не должен быть слишком длинным, это правда? _что насчет этого?

Ну, этот вопрос нельзя обобщать:

(1) Если даInnoDBМеханизм хранения, первичный ключ не должен быть слишком длинным;

(2) Если даMyISAMМеханизм хранения мало на что влияет;

Давайте возьмем простой каштан, чтобы проиллюстрировать знания о предварительном заказе.

Предположим, есть таблица данных:

t(id PK, name KEY, sex, flag);

в:

(1) id — первичный ключ;

(2) Общий индекс строится для имени;

Предположим, что в таблице четыре записи:

1, shenjian, m, A

3, zhangsan, m, A

5, lisi, m, A

9, wangwu, f, B

Если механизм храненияMyISAM, структура его индекса и записи такова:

(1) Имеется отдельная запись хранения области (запись);

(2) индекс первичного ключа имеет ту же структуру, что и обычный индекс, и оба хранят указатель записи (пока что он понимается как указатель);

Голос за кадром:

(1) индекс первичного ключа и записи не хранятся вместе, поэтому это некластеризованный индекс;

(2) MyISAM не может иметь PK;

Когда MyISAM использует индекс для поиска, он сначала находит указатель записи в дереве индексов, а затем находит конкретную запись с помощью указателя записи.

Голос за кадром: независимо от индекса первичного ключа или обычного индекса процесс одинаков.

InnoDBОн другой, структура его индекса и записи такова:

(1) индекс первичного ключа хранится вместе с записью;

(2) Обычный индекс хранит первичный ключ (это не указатель);

Голос за кадром:

(1) индекс первичного ключа хранится вместе с записью, поэтому он называется кластерным индексом;

(2) InnoDB должен иметь кластеризованный индекс;

Когда InnoDB запрашивает индекс первичного ключа, он может напрямую найти запись строки.

Однако при запросе через общий индекс сначала будет запрошен первичный ключ, а затем дерево индекса будет дважды пройдено по индексу первичного ключа.

вернуться к сути,Почему первичный ключ InnoDB не должен быть слишком длинным?

Предположим, естьПользовательский центрСценарий, включая идентификационный номер, идентификационную карту MD5, имя, дату рождения и другие бизнес-атрибуты, эти атрибуты имеют требования к запросу.
Самый простой способ придумать дизайн:

  • ID как первичный ключ

  • индекс по другим свойствам

user(id_code PK,
id_md5(index),
name(index),
birthday(index));

Дерево индексов и структура записей строк в настоящее время выглядят следующим образом:

  • кластеризованный индекс id_code, связанные записи строк

  • Другие индексы, хранящие значение атрибута id_code

Идентификационный номер id_code представляет собой относительно длинную строку, и каждый индекс хранит это значение.В случае большого количества данных и драгоценной памяти MySQL имеет ограниченный буфер, хранимый индекс и данные будут уменьшены, а вероятность дискового IO будет уменьшено.

Голос за кадром: При этом увеличится и место на диске, занимаемое индексом.

На этом этапе следует добавить самоувеличивающийся столбец идентификатора, не имеющий бизнес-значения:

  • Самоувеличивающийся как кластеризованный индекс с идентификатором, связанными записями строк

  • Другие индексы, в которых хранятся значения идентификаторов

user(id PK auto inc,
id_code(index),
id_md5(index),
name(index),
birthday(index));

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

Суммировать

(1) индекс MyISAM хранится отдельно от данных, лист индекса хранит указатель, а индекс первичного ключа мало чем отличается от обычного индекса;

(2) кластеризованный индекс InnoDB и строки данных хранятся единообразно, кластеризованный индекс хранит саму строку данных, а обычный индекс хранит первичный ключ;

(3) InnoDB не рекомендует использовать слишком длинные поля в качестве PK (в это время вы можете добавить ключ автоинкремента PK), MyISAM не имеет значения;
Надеюсь, что это ответ на ваш вопрос.

Вы можете продолжать задавать вопросы и отвечать на любые вопросы.

Статьи по Теме:
"Буферный пул (буферный пул), на этот раз я полностью понимаю!》
"Буфер записи (буфер изменения), на этот раз я полностью понимаю! 》

Категории