Рабочий процесс тюнинга

Шаг 1 — найди запрос, который реально важен

Нельзя тюнить то, что не измерил, а интуиция про «медленный запрос» почти всегда неверна. Первый ход — pg_stat_statements — расширение, агрегирующее каждый выполненный запрос (нормализованный, со снятыми литералами) и отслеживающее его суммарную стоимость. Важное число — total_exec_time, а не mean_exec_time: запрос на 5 мс, выполненный 2 миллиона раз, стоит больше общего времени БД, чем 4-секундный отчёт, запущенный дважды, и срезание первого экономит больше.

-- Запросы, съедающие больше всего общего времени на сервере:
SELECT
  substring(query, 1, 60)        AS query,
  calls,
  round(total_exec_time)         AS total_ms,
  round(mean_exec_time, 2)       AS mean_ms,
  round(100 * total_exec_time / sum(total_exec_time) OVER (), 1) AS pct
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Читай колонку pct: тюнинг это Парето. Если один запрос — 78% общего времени, это весь твой день; остальное — шум, пока не станет важным. Сортируй по total_exec_time, бери верхний, игнорируй всё остальное.

Шаги 2–4 — воспроизведи, диагностируй, почини наименьшее

Когда у тебя есть тот самый запрос, цикл механистичен:

• Воспроизведи через EXPLAIN (ANALYZE, BUFFERS) (урок 01). Это истина в последней инстанции — никогда не тюнь по одному тексту запроса.
• Диагностируй, сопоставив улики с одной корневой причиной (весь раздел, сжато):
  • Большой зазор оценка-против-факта по строкам? → устаревшая или предполагающая независимость статистика → ANALYZE или CREATE STATISTICS (урок 03).
  • Seq Scan на селективном фильтре, высокие read= буферы? → отсутствующий индекс → добавь (CONCURRENTLY), по главе индексов трека databases.
  • Живых строк мало, но буферы/размер огромны? → bloat → вакуум/pg_repack (урок 04).
  • Оценки в порядке, скан верный, всё равно медленно? → данных правда слишком много → перепиши, пагинируй или предагрегируй.
• Примени наименьший фикс, адресующий эту причину. Одно изменение. Точечный ANALYZE лучше нового индекса; новый индекс лучше переписывания; переписывание лучше изменения конфига — в этом порядке локальности, ведь наименьшее изменение имеет наименьший радиус поражения.
• Проверь, перезапустив EXPLAIN (ANALYZE, BUFFERS) и убедившись, что число сдвинулось. Затем пересмотри pg_stat_statements после реального трафика — иногда фикс смещает узкое место на следующий запрос, и цикл повторяется.

Почему «измеряй, не гадай» — это вся дисциплина

Каждый анти-паттерн тюнинга — это догадка, пропустившая шаг измерения:

• Преждевременная индексация — добавление индексов «на всякий случай» до того, как хоть один запрос доказал, что нужен. Каждый индекс облагает налогом каждую запись (глава индексов трека databases это количественно оценивает) и может вводить планировщик в заблуждение; неиспользуемый индекс — чистая цена. Добавляй индекс только после того, как EXPLAIN покажет Seq Scan, который он уберёт.
• Карго-культ конфига — копирование значений random_page_cost или work_mem из блога без измерения своей нагрузки.
• Слепое переписывание — джуниор из хука переписал SQL трижды, потому что текст казался медленным, когда реальной причиной была устаревшая оценка, которую переписывание не могло тронуть.

Сеньорский рефлекс обратен: каждому изменению предшествует измерение, его оправдывающее, и следует измерение, его подтверждающее. Это и заставляет цикл сходиться, а не молотить впустую. (Капстоун раздела 09 прогоняет этот самый цикл от начала до конца на реалистичном аналитическом API — этот урок — метод, который он применяет.)