N+1 и деградация SQL: production playbook

Большая часть проблем производительности backend-а упирается не в CPU, а в запросы к БД.

Самый дорогой класс ошибок — N+1 и неуправляемый рост SQL-нагрузки.

Проще говоря

Как быстро находить и устранять N+1, медленные запросы и деградацию БД в реальных сервисах. Ниже — что именно делать на практике и где чаще всего ошибаются.

1) Симптомы, которые нельзя игнорировать

• p95 ответа растёт с числом записей,
• один endpoint делает десятки/сотни запросов,
• БД уходит в high CPU при обычном трафике,
• random timeouts на «обычных» страницах.

2) Как диагностировать быстро

Минимальный порядок:

1. включить query log на проблемном endpoint,
2. посчитать количество SQL-запросов на 1 request,
3. найти повторяющиеся селекты,
4. проверить EXPLAIN на самых тяжёлых запросах.

3) Антидоты против N+1

• eager loading,
• batched queries,
• правильные join-ы,
• precomputed projections для дорогих экранов.

Цель: вместо 101 запроса делать 2–5.

4) Индексы: не «побольше», а по паттернам

Индекс должен соответствовать реальному фильтру/сортировке.

Проверяй:

• где WHERE,
• где ORDER BY,
• покрывает ли индекс select-path,
• нет ли избыточных/дублирующих индексов.

5) Частые ошибки

1. Лечат N+1 кэшем вместо фикса SQL.
2. Добавляют индексы без анализа write-overhead.
3. Делают «универсальный» репозиторий с непредсказуемыми запросами.
4. Не ограничивают page size и получают взрывные выборки.

6) Чеклист стабилизации

• SQL budget на endpoint (например, ≤10 запросов)
• p95 latency budget
• EXPLAIN для top N запросов
• алерт на резкий рост query count
• регрессионный тест на N+1

Короткая история из команды

На практике эффект появился только после того, как команда закрепила подход в ежедневных решениях, а не оставила его как разовую инициативу.

Вывод

N+1 — не мелкая оптимизация, а архитектурная дисциплина доступа к данным.

Когда у каждого endpoint есть SQL-бюджет и контроль регрессий, БД перестаёт быть «непредсказуемым узким местом».

Практический сценарий внедрения

Если внедрять подход поэтапно, лучше идти от самого болезненного потока: выбрать один критичный user-journey, зафиксировать текущие метрики и применить изменения только на этом участке. Такой подход снижает риск и даёт быстрый доказуемый эффект для команды.

Метрики, которые важно отслеживать

• p95/p99 latency для ключевых операций,
• error rate и доля retry/резервный сценарий,
• время восстановления после сбоев,
• стоимость обработки запроса/события,
• доля регрессий после релизов.

Без метрик даже сильные архитектурные решения быстро превращаются в набор гипотез.

Что обычно идёт не так

1. Команда пытается внедрить всё сразу вместо поэтапного поэтапный запуск.
2. Нет владельца архитектурного решения и контроль расслаивается.
3. Решение есть в документации, но не встроено в CI/CD и runbook.
4. После внедрения нет регулярного review, и качество снова деградирует.

Пошаговый план на 30 дней

• Неделя 1: базовый уровень, ограничения, целевые KPI.
• Неделя 2: внедрение в одном потоке + алерты.
• Неделя 3: стабилизация, фиксы edge-cases.
• Неделя 4: масштабирование на соседние модули и обновление стандартов команды.

Термины простыми словами

• Политика повторов — правила повторных попыток (когда, сколько раз и с каким backoff), чтобы не усилить сбой.

Этот блок нужен, чтобы статью можно было читать без предварительного контекста по всем терминам.

Как применять это в живом проекте

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

Хорошая последовательность: сначала фиксируем baseline, затем внедряем минимально жизнеспособную версию решения, после чего смотрим на метрики 1–2 недели. Если эффект подтверждается, масштабируем на соседние сценарии. Если нет — откатываем без драм и пересобираем гипотезу.