Что такое UUID v4 и UUID v7
UUID v4 несёт 122 случайных бита. В нём нет ни последовательности, ни часов, ни данных для расшифровки, поэтому это самый безопасный вариант, когда идентификатор не должен ничего раскрывать и создаётся где угодно. UUID v7 оставляет 74 случайных бита, но первые 48 отдаёт метке времени Unix в миллисекундах (плюс несколько бит счётчика внутри миллисекунды), поэтому два значения, созданные с разницей в минуту, сравниваются как строки в том же порядке.
Следствие проявляется в индексе. При случайных ключах каждая вставка попадает в новое место B-дерева: страницы разбиваются, рабочий набор растёт, а скорость записи падает по мере увеличения таблицы. С v7 вставки приходят к правому краю дерева и ведут себя почти как автоинкремент, сохраняя возможность создавать значение на любом узле без координации.
Платить за это приходится раскрытием информации. Метка времени в v7 сообщает любому, у кого есть значение, примерное время создания — с точностью до миллисекунды. Если это нежелательно, правильный ответ — v4. Оба формата определены в RFC 9562; v4 — более старый, перенесённый из RFC 4122.
Как использовать
- Нужны ключи для индексируемой таблицы? Берите v7 — генератор выше переключает версию одним кликом.
- Идентификатор публикуется или не должен ничего раскрывать? Берите v4.
- Переводите существующий столбец? Преобразовать значения нельзя; новые строки могут использовать v7, старые останутся v4 — оба допустимы в одном столбце.
Сценарии
- Таблицы событий и логов, куда строки только добавляются: упорядоченный ключ держит индекс компактным.
- Публичные URL и id в API, где v4 не раскрывает время создания ресурса.
- Несколько пишущих узлов, где обе версии создаются без координатора, а v7 дополнительно даёт приблизительный порядок.
Сравнение UUID v4 и UUID v7 с другими форматами
| Вариант | Когда использовать |
|---|---|
UUID v4 | Случайный, 122 бита. Лучший выбор, когда порядок не важен. |
UUID v7 | Время Unix в мс + случайные биты. Лучший выбор для индексируемых ключей. |
UUID v6 | Та же идея порядка для раскладки v1; сохраняет старые часы с шагом 100 нс. |
Хранение | Идентично: 16 байт, 36 символов, одни и те же типы в базах. |
Примеры кода
Оба в JavaScript
// v4 — встроено
const v4 = crypto.randomUUID();
// v7 — пакет uuid
import { v7 as uuidv7 } from 'uuid';
const v7 = uuidv7(); // 019535d9-3df7-79fb-b466-fa907fa17f9e
Оба в Python
import uuid
uuid.uuid4() # случайный
uuid.uuid7() # упорядоченный, Python 3.14+
Чтение метки времени
import uuid
u = uuid.UUID('019535d9-3df7-79fb-b466-fa907fa17f9e')
print(u.version) # 7
# PostgreSQL 18 умеет это в запросе:
# SELECT uuid_extract_timestamp(id) FROM events;
Частые вопросы
Заменяет ли v7 версию v4?
Нет. RFC 9562 определяет обе, и ни одна не устарела. v7 лучше подходит для ключей в индексе, а v4 остаётся правильным выбором, когда время создания не должно быть восстановимо или нужно просто непредсказуемое значение.
UUID v7 остаётся уникальным?
Да. 48 бит отданы времени, 74 остаются случайными, а RFC требует монотонного счётчика в пределах одной миллисекунды. Два значения, созданные в одну миллисекунду одним процессом, всё равно различаются — счётчик увеличивается.
Можно ли перевести столбец с v4 на v7?
Переписать существующие значения в форму v7 нельзя: биты v4 случайны и метки времени не содержат. Но можно оставить старые строки как есть и создавать v7 для новых: оба варианта удовлетворяют типу uuid, а выигрыш для индекса касается всего, что вставляется с этого момента.