Не уверены, что выбрать? UUID v4 — для большинства случаев. v7 или ULID — если идентификатор используется как первичный ключ в базе (сортируются по времени, дружелюбны к индексу InnoDB).
Первичный ключ в InnoDB — кластерный индекс: строки физически хранятся в его порядке. Случайный v4 попадает в случайные места B-tree, вызывая расщепление страниц, фрагментацию и рост объёма. v7 и ULID монотонны по времени — вставки идут в конец индекса, как у автоинкремента, но без глобальной координации и без утечки числа записей. Нужен непоследовательный публичный идентификатор — берите v7/ULID, а не v4.
Идентификаторы генерируются в браузере через crypto.getRandomValues и никуда не отправляются.
Чем UUID v7 отличается от v4?
v4 полностью случаен. v7 содержит в старших битах метку времени в миллисекундах, поэтому идентификаторы упорядочены по времени создания и сортируются как строки.
Почему v7 или ULID лучше как первичный ключ в InnoDB?
Первичный ключ в InnoDB — кластерный индекс, и строки физически хранятся в его порядке. Случайный v4 вставляется в случайные места B-tree, вызывая расщепление страниц и фрагментацию. v7 и ULID монотонны по времени, поэтому вставки идут в конец индекса, как у автоинкремента, но без глобальной координации и без утечки числа записей.
Отправляются ли сгенерированные идентификаторы на сервер?
Нет. Всё генерируется в браузере через crypto.getRandomValues, страница не делает ни одного сетевого запроса.
Гарантируется ли строгий порядок v7 в пределах одной миллисекунды?
Нет. В пределах одной миллисекунды несколько v7 упорядочены только по случайной части. Строгая монотонность внутри миллисекунды — задача серверного генератора со счётчиком; для утилиты этого достаточно.
Читайте по теме: почему выбор первичного ключа влияет на БД — ACID-принципы, уровни изоляции транзакций и архитектура Symfony-приложения.