Primary keys

Первичный ключ однозначно идентифицирует строку и служит опорой для foreign keys, identity в ORM и часто порядка clustered index. Он должен быть уникальным, non-null и стабильным на всё время жизни строки.

| Стратегия | Плюсы | Минусы | |-----------|-------|--------| | Сурrogate (`BIGSERIAL`, UUID) | Стабилен, простые join | UUID раздувают индексы; последовательные ID выдают объём | | Естественный (email, SKU) | Понятен людям | Может меняться; составные ключи усложняют ORM | | Составной (`(tenant_id, local_id)`) | Подходит для multi-tenant и шардинга | Шире FK-столбцы; трение с ORM |

					-- PostgreSQL: time-ordered UUID v7 или bigint identity
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email TEXT NOT NULL UNIQUE
);
				

В InnoDB первичный ключ задаёт порядок строк в кластере — случайные UUID при вставке вызывают page splits; монотонные ключи улучшают локальность insert, но раскрывают порядок. Для высоконагруженного OLTP предпочитайте `BIGINT` identity, если не нужна глобальная уникальность без координации.

На интервью: обоснуйте выбор ключа для конкретной таблицы — почему не email как PK, когда UUID лучше serial, как миграции переживают смену ключа.

Типовые ошибки: отсутствие primary key (ломает replication tools, усложняет ORM); изменяемый естественный ключ как PK; `INT`, когда таблица перевалит за 2 млрд строк; случайный UUID PK на write-heavy InnoDB без замера bloat.

Компромисс — между производительностью вставок, глобальной уникальностью, читаемостью для людей и безопасностью миграций: выбирайте форму ключа под то, как строки создаются, ссылаются и шардируются.

Чеклист:

• Сформулируйте, почему PK не изменится за жизнь строки.
• Сравните surrogate и natural для домена.
• Упомяните влияние на clustering / локальность индекса.
• Объясните, как дочерние таблицы ссылаются на PK.
• Отметьте последствия для шардинга или multi-tenant.