Первичный ключ в MySQL: INT (n) или UUID как varchar (36)
Имеет смысл использовать UUID в качестве первичного ключа в MySQL?
Каковы были бы за и против использования UUID вместо регулярного INT около проблемы ручных запросов?
3 ответа
Основным недостатком UUID является то, что вам нужно создать их заранее, если вы хотите вернуться к записи для дальнейшего использования впоследствии (например, добавление дочерних записей в зависимых таблицах с внешним ключом):
INSERT INTO table (uuidfield, someotherfield) VALUES (uuid(), 'test'));
не позволит вам увидеть новое значение UUID, и поскольку вы не используете обычный auto_incremented первичный ключ, вы не можете использовать last_insert_id () для получить его. Вам нужно будет сделать это в два этапа:
SELECT @newuid := uuid();
INSERT INTO table (uuidfield, someotherfield) VALUES (@newuid, 'test');
INSERT INTO childtable ..... VALUES (@newuid, ....);
Я могу думать о том, что ваш идентификатор будет уникальным не только в вашей таблице, но и во всех других таблицах вашей базы данных. Более того, он должен быть уникальным среди любой таблицы из любой базы данных в мире.
Если семантика вашей таблицы нуждается в этой функции, используйте UUID. В противном случае просто используйте простой INT ID (быстрее, проще в обработке, меньше).
Недостатки UUID в том, что он более громоздкий и, следовательно, немного медленнее для поиска. Трудно вводить длинную шестнадцатеричную строку для каждого специального запроса. Он решает проблему, которой у вас может не быть, например, уникальность нескольких серверов.
Кстати, INT (n) всегда является 32-битным целым числом в MySQL, аргумент (n) не имеет ничего общего с размером или диапазоном допустимых значений. Это всего лишь подсказка по ширине дисплея.
Если вам нужно целое число с диапазоном значений, превышающим то, что предоставляет 32-битный, используйте BIGINT .