Первичный ключ с использованием timestamp + guuid

Question

• 1000

Answer 1

INSERT: guid + epo c будет несколько медленнее. Он станет намного медленнее, когда таблица больше, чем может поместиться в buffer_pool.

SELECT: Если вы склонны обращаться только к «последним» данным, то epoc + guid может быть значительно быстрее. («местонахождение ссылки»)

Если вы используете UUID «Тип 1» и перетасовываете биты, то вы получаете обе функции (уникальность и упорядоченность по времени) в одном поле. (Чем меньше, тем лучше.) Подробнее: http://mysql.rjweb.org/doc.php/uuid Кроме того, MySQL 8 имеет эквивалентные функции.

Для дальнейшего обсуждения укажите тип данных, размер данных и тип вставок / выборок / обновлений / удалений.

Answer 2

Строго говоря, первичный ключ - это концепция logi c, а не физическая концепция, но обычно она реализуется с использованием индекса (который является физической концепцией). В InnoDB этот индекс будет влиять на порядок, в котором хранятся данные. Это означает, что при записи в таблицу ему придется переупорядочить данные в порядке первичного ключа, если значение первичного ключа не добавлено аккуратно в конец.

Следовательно, используя epoc + guid должен быть намного быстрее, чем guid + epo c, при условии, что epo c отражает время записи данных на диск. Если epo c - это какое-то другое значение - дата бизнес-транзакции, дата рождения, что угодно - разницу труднее предсказать.

Поскольку GUID гарантированно уникальны, я не уверен, зачем вам вообще иметь guid + epo c.