Что лучше и правильнее использовать в качестве первичного ключа: автоинкремент или UUID?

Или же существенного различия между ними нет? Многие пишут, что автоинкремент - это плохой выбор и в качестве первичного ключа лучше использовать UUID. Однако весомых аргументов в пользу данного утверждения я так и не нашел. Проблемы со слиянием двух таблиц с автоинкрементом, перебор сущностей и т.д. - это лишь частные случаи, и далеко не всегда они являются критичными.


Ответы (2 шт):

Автор решения: Aziz Umarov

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

обновлено. Почитайте Первичный ключ – GUID или автоинкремент?

→ Ссылка
Автор решения: Ainar-G

Коллеги уже привели аргументы в пользу автоинкремента. Вот некоторые аргументы в пользу UUID:

  • Сокрытие информации. Тут всё просто. Если кто-то видит, что в вашей системе есть, например, пользователь с ID 42, он может понять, что в системе как минимум 42 пользователя, а также что в системе скорее всего есть пользователи 41 и 43. По UUID он мало что поймёт.

  • Источник идентификатора. UUID может быть сгенерирован как на стороне приложения, так и на стороне СУБД. В случае с автоинкрементом, только на стороне СУБД.

  • Шардирование. Во многом выходит из предыдущего пункта. Держать распределённый счётчик часто тяжело, и с увеличением числа узлов будет страдать быстродействие системы. С UUID такой проблемы нет.

Коллеги упоминали быстродействие, но тут стоит отметить, что многие СУБД имеют специальный тип UUID, который как правило занимает 128 бит. На большинстве современных машин это два слова, в то время как обычный BIGINT или INTEGER — одно. Реальный «ущерб» от UUID надо смотреть на конкретной машине и для конкретных данных.

→ Ссылка