Различия между int и uuid в mysql

Если я установил ключ primary id в int type (auto increment) или установил его в UUID, какая разница между этими двумя в производительности базы данных (select, insert...) и почему?

Ответ 1

UUID возвращает универсальный уникальный идентификатор (надеюсь, он также уникален, если импортирован в другую БД)

Для цитаты из mysql doc (выделено мной):

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

С другой стороны, простой ключевой ключ INT (например, автоинкремент) будет возвращать уникальное целое для конкретной таблицы БД и БД, но не универсально уникально (поэтому, если импортировано в другой шанс БД заключается в конфликтах с первичными ключами)

В плане производительности не должно быть заметных различий, используя auto-increment over UUID. Большинство сообщений (в том числе некоторые авторы этого сайта), заявляют как таковые. Конечно, UUID может занимать немного больше времени (и пространства), но это не является узким местом для большинства (если не всех) случаев. Наличие столбца Primary Key должно сделать оба варианта равными по производительности. См. Ссылки ниже:

(UUIDvs auto-increment результаты производительности, адаптированные из Мифы, GUID vs Autoincrement)

UUID плюсы/минусы (адаптировано из Первичные ключи: ID против GUID s)

GUID Плюсы

Уникально для каждой таблицы, каждой базы данных, каждого сервера

Позволяет легко объединять записи из разных баз данных.

Позволяет легко распределять базы данных на нескольких серверах.

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

В большинстве сценариев репликации требуется столбцы GUID в любом случае
GUID Против

Это 4 раза больше, чем традиционное 4-байтовое значение индекса; это может иметь серьезные последствия для производительности и хранения, если вы не внимательны.

Громоздко отлаживать (where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')

Сгенерированный GUID должен быть частично последовательным для лучшей производительности (например, newsequentialid() на SQL 2005) и разрешить использование кластеризованные индексы.

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