Генерируйте сортируемые 26-символьные ULID (Crockford base32) и декодируйте встроенную метку времени обратно в дату. Отлично для первичных ключей БД.
Сортируемые уникальные идентификаторы. ULID состоит из 26 символов: первые 10 кодируют время создания в миллисекундах, последние 16 — случайные. Это делает их лексикографически сортируемыми и безопасными для использования в качестве ключей. Генерируется в браузере.
ULID — это 128-битный идентификатор, той же ширины, что UUID, разделённый на две части: 48-битная миллисекундная метка времени, за которой следуют 80 случайных бит. Он выводится как 26 символов Crockford base32, а не как 36-символьный гипененированный hex UUID, поэтому он короче, не зависит от регистра и свободен от символов, которые легче всего перепутать — I, L, O и U исключены из алфавита.
Существенная разница не в кодировке, а в порядке. Поскольку метка времени занимает старшие биты, а base32 сохраняет порядок байтов, сортировка ULID как обычных строк сортирует их по времени создания. Два ID, созданные в ту же миллисекунду, откатываются к своей случайной части, но между миллисекундами порядок точен.
UUIDv4 равномерно случаен — это именно то, что вам не нужно в кластеризованном индексе. Каждая вставка попадает в случайную точку B-дерева, поэтому база данных постоянно дробит страницы и обращается к холодным. Индекс растёт больше, чем нужно, а пропускная способность записи падает по мере роста таблицы. Это хорошо задокументированная проблема UUID-первичных ключей в InnoDB MySQL и в SQL Server.
Идентификатор, упорядоченный по времени, добавляется у правого края индекса — тот же шаблон доступа, что у автоинкрементного целого. Вы сохраняете преимущества глобально уникального ключа, сгенерированного клиентом, — без обращения за ID, без координации между сервисами, безопасное слияние между шардами, — без фрагментации индекса.
UUIDv7, стандартизированный в RFC 9562, делает то же, что ULID, в стандартном формате и раскладке UUID. Если ваш стек уже имеет нативные типы столбцов и инструменты UUID, UUIDv7 обычно лучший выбор сейчас просто потому, что он встраивается в существующую экосистему. ULID остаётся привлекательным, когда вы хотите более короткую, дружелюбную текстовую форму в URL или журналах.
В любом случае ясно: метка времени видима любому, у кого есть ID. Времена создания утечь, а соседние ID выдают порядок — не используйте их для чего-либо, где перечисление или время чувствительны. И при 80 случайных битах в миллисекунду коллизии не являются практической проблемой, но ULID — не секреты и никогда не должны использоваться как токены возможностей.