Какую версию UUID выбрать?
Для большинства задач — версию 4: она состоит из случайных битов и ничего не сообщает о том, где и когда была создана. Если записи должны сортироваться по времени вставки, берите версию 7. Версии 3 и 5 нужны, когда идентификатор вычисляется из имени и должен повторяться при тех же исходных данных, версия 6 — когда в системе уже есть идентификаторы версии 1, а версии 1 и 2 остаются ради совместимости со старыми системами.
Можно ли использовать UUID версии 4 как секретный токен?
Для одноразовых ссылок — с оговорками, для паролей и ключей доступа — нет. Угадать 122 случайных бита нельзя, но идентификаторы принято считать несекретными: они попадают в журналы сервера, адресную строку и заголовок Referer. Для доступа заводите отдельный токен, а UUID оставляйте идентификатором.
Могут ли два сгенерированных UUID совпасть?
Теоретически да, практически — нет. В версии 4 случайными являются 122 бита, что дает примерно 5,3 × 10^36 вариантов, поэтому вероятность совпадения пренебрежимо мала даже при миллиардах идентификаторов. В версиях, где часть разрядов занята временем, уникальность обеспечивается сочетанием метки времени со случайной частью или адресом узла.
Почему версия 4 хуже ложится в индекс базы данных?
Каждое новое значение попадает в случайное место индекса, поэтому вставки разбрасываются по дереву, страницы приходится чаще подгружать и делить. На больших таблицах это заметно. Если порядок вставки важен, берите версию 7: она начинается с метки времени и растет с одного края.
Соответствуют ли идентификаторы стандарту?
Да. Идентификаторы всех версий соответствуют формату из RFC 4122 (обновлен в RFC 9562): 32 шестнадцатеричные цифры, разбитые дефисами на группы 8-4-4-4-12, с номером версии и вариантом в отведенных для них позициях. Случайные биты берутся из криптографически стойкого источника случайности.