UUID: когда автоинкремент недостаточно

Твоя база данных использует автоинкрементные ID. 1, 2, 3, 4... Просто.

Затем ты объединяешь две базы данных. Или раскрываешь ID в URL. Или кто-то понимает, что может угадывать данные других пользователей, инкрементируя ID в URL.

У последовательных ID есть проблемы. UUID решают некоторые из них.

Что такое UUID?

Universally Unique Identifier / Универсально уникальный идентификатор. 128-битное число, обычно отображаемое как 32 шестнадцатеричных символа с тире:

550e8400-e29b-41d4-a716-446655440000

Математика за генерацией UUID делает коллизии астрономически маловероятными. Ты можешь генерировать UUID на разных машинах, в разное время, без координации, и они не столкнутся.

Почему не просто использовать автоинкремент?

Безопасность. Последовательные ID утекают информацию. Если твой user ID 15847, атакующие знают, что есть как минимум 15846 других пользователей. Они могут перечислять ресурсы, пробуя последовательные ID.

Распределённые системы. Несколько серверов, генерирующих ID, нуждаются в координации, чтобы избежать дубликатов. UUID не нуждаются в координации.

Слияние данных. Объединение баз данных с последовательными ID — кошмар. UUID сливаются чисто.

Офлайн-создание. Мобильные приложения могут создавать записи офлайн с UUID. Нет нужды ждать ID, назначенного сервером.

Версии UUID

Не все UUID создаются одинаково.

Версия 1: Основан на timestamp и MAC-адресе. Уникален, но раскрывает, когда и где был создан.

Версия 4: Случайный. Самый распространённый. Без утечки информации.

Версия 7: Основан на timestamp, но сортируемый. Новые базы данных выигрывают от этого.

Для большинства применений версия 4 (случайный) — правильный выбор.

Компромиссы

UUID не бесплатны.

Размер. 128 бит vs 32 бита для целого числа. Большие индексы, больше хранилища.

Читаемость. user/15 легче запомнить, чем user/550e8400-e29b-41d4-a716-446655440000.

Производительность. Случайные UUID вызывают фрагментацию индекса в некоторых базах данных. UUID v7 решает это.

Отладка. Поиск UUID в логах утомителен по сравнению с простыми числами.

Когда использовать что

Используй автоинкремент, когда:

• Только внутреннее, никогда не раскрывается пользователям
• Простые приложения, одна база данных
• Человеческая читаемость важна

Используй UUID, когда:

• ID появляются в URL или API
• Несколько систем создают записи
• Безопасность через неясность помогает
• Слияние данных возможно

Практические советы

Не используй UUID как первичные ключи в MySQL. Используй их как вторичный уникальный столбец вместо этого. Кластеризованные индексы MySQL плохо работают со случайными UUID.

Рассмотри UUID v7. Если твоя база данных поддерживает его, сортируемые по timestamp UUID дают тебе лучшее из обоих миров.

Удаляй тире для URL. 550e8400e29b41d4a716446655440000 всё ещё валидный UUID и короче в URL.

---

UUID решают реальные проблемы, которые последовательные ID не могут. Но они не всегда правильный выбор. Выбирай на основе своих фактических требований, а не потому что UUID звучат более профессионально.