Indexes

PK/FK & basics: убедиться, что есть PK на (Products.id), (Orders.id) и FK индексы на (Orders.user_id) и (OrderItems.order_id), (OrderItems.product_id).Компонентные/покрывающие индексы для быстрых чтений:
индекс по (Orders(user_id, created_at)) для списка заказов пользователя.индекс по (OrderItems(order_id, product_id)) (и включить (qty) / (price) как INCLUDE/covering, если СУБД поддерживает).индекс по (OrderItems(product_id)) для аналитики/сумм продаж.Учесть стоимость: индексы ускоряют SELECT, но замедляют INSERT/UPDATE и увеличивают размер хранилища.

Денормализация (чтобы читать без тяжёлых JOIN)

Сохранять цену на момент покупки в (OrderItems.price) (чтобы история не слетала при смене цены).Сохранять имя/артикул товара в (OrderItems) при необходимости отображения истории без JOIN.Хранить предрасчитанную сумму заказа в (Orders.total) и/или агрегаты (суммарные продажи) в отдельной таблице/материализованном виде.Использовать materialized views / OLAP-реплики для сложных агрегаций.Компромисс: дублирование данных повышает скорость чтения, но требует логики синхронизации при обновлениях (сложность, вероятность рассинхронивания).

Кеширование и чтение под высокой нагрузкой

L1/L2 кеш в приложении (оперативный объектный кеш), распределённый кеш (Redis/Memcached) для часто читаемых данных (каталог, карточки товара, предрасчитанные агрегаты).Read-replicas: направлять чтения на реплики, писать в мастер; учитывать задержку репликации (eventual consistency) — возможны устаревшие данные.Пагинация по ключу (keyset) вместо OFFSET для больших наборов.Компромиссы: реплики и кеши дают большую пропускную способность чтения, но вводят сложность согласованности и инвалидации.

Транзакции, блокировки и уровни изоляции для корректных заказов

Процесс создания заказа:
начать транзакцию;проверить/зарезервировать остаток товара атомарно (варианты ниже);вставить (Orders) и (OrderItems) (с сохранением цены в (OrderItems.price));подтвердить (commit).Обеспечение корректности запасов:
Пессимистический подход: (SELECT stock FROM Products WHERE id = ... FOR UPDATE) -> проверить (stock \ge qty) -> (UPDATE Products SET stock = stock - qty). Надёжно, но блокирует строки.Оптимистический подход: хранить версию/nonce (или использовать WHERE (stock \ge qty) в UPDATE): (UPDATE Products SET stock = stock - :qty WHERE id = :id AND stock >= :qty); проверять число затронутых строк. Подходит при высокой конкуренции и коротких транзакциях.Уровни изоляции:
READ COMMITTED + явные FOR UPDATE/atomic UPDATE — хороший компромисс: производительность и предсказуемые локи.SERIALIZABLE — обеспечивает отсутствие фантомов и аномалий, но увеличивает вероятность конфликтов и откатов (retry), снижая пропускную способность при высокой конкуренции.Рекомендация: использовать READ COMMITTED (или местный default MVCC) + явные row-level locks или атомарные UPDATE для decrement; рассмотреть SERIALIZABLE только если бизнес строго требует абсолютной сериализации и нагрузка позволяет ретраи.Идемпотентность: применить idempotency-key при повторных запросах оплаты, чтобы избежать дублирования заказов.

Дополнительные меры

Горизонтальное масштабирование: шардирование по пользователям или по заказам при очень большом объёме; сложность распределённой транзакции.Connection pooling, prepared statements, batch inserts для OrderItems.Мониторинг: метрики задержек реплик, частоты deadlock/rollback, процент кеш‑хитов.Тестирование под нагрузкой и chaos‑tests для выявления конфликтов и узких мест.

Краткий список компромиссов

Индексы/денормализация: +чтение, −сложность обновлений, −место, −возможны рассинхронизации.Кеш/реплики: +пропускная способность чтения, −стали́стость данных (eventual consistency), −сложность инвалидации.Пессимистические блокировки: +корректность, −пропускная способность (блокировки, ожидания).SERIALIZABLE: +минимум аномалий, −большое число откатов и снижение throughput при конкуренции.Шардирование: +масштаб, −сложная логика транзакций и запросов cross-shard.

Если нужно, могу приложить пример SQL-паттернов: индексы, атомарный decrement, транзакция создания заказа.