Базы Данных (Data Base) | SQL & NoSQL. PostgreSQL, MySQL и Big Data. Уроки для Backend и Data Engineer. Архитектура БД, Оптимизация и Design.
IT и технологии · 26 февраля 2026 г.
🧱 Антипаттерн: использование UUID как Primary Key без оглядки — 26 февраля 2026 г. в 12:50:13.292
🧱 Антипаттерн: использование UUID как Primary Key без оглядки На первый взгляд, UUID — классный способ генерировать уникальные идентификаторы: – не зависят от последовательности – удобны для распределённых систем – безопасны для внешнего экспонирования Но если ты просто заменишь SERIAL или BIGINT на UUID в качестве PK — жди сюрпризов: ❌ В чём подвох: – Производительность INSERT'ов резко падает: UUID случайные → нет locality → индекс (обычно B-Tree) постоянно фрагментируется – Индексы пухнут: UUID = 16 байт, BIGINT = 8 байт. Разница кажется небольшой, но на больших объёмах — это боль – Чтение медленнее: за счёт увеличенного размера индексов и меньшего кэш-хита ✅ Как избежать: 1. Если нет жёсткой необходимости в UUID — не используй их как PK 2. Нужен UUID? Сделай его вторичным индексом, а PK оставь автоинкрементным 3. Или хотя бы используй UUID v7 (новый стандарт с time-based префиксом) — он улучшает локальность по сравнению с v4 Пример: CREATE TABLE users ( id BIGSERIAL PRIMARY KEY, public_id UUID DEFAULT gen_random_uuid() UNIQUE, name TEXT ); → Внутри БД — быстрый BIGINT, → Для внешних API — UUID. Удобно и производительно. #db 👉 @database_info