EXPLAIN ANALYZE — не магия. Как читать план, чтобы не лечить не то

EXPLAIN ANALYZE — не магия. Как читать план, чтобы не лечить не то

Коллеги, давайте разберем план выполнения. EXPLAIN ANALYZE полезен только когда вы смотрите не на «красивое дерево», а на расхождение между оценкой и фактом.

Сначала ищем три вещи:
— где планировщик ошибся в кардинальности;
— какой узел дал основной вклад во время;
— не упёрлись ли вы в I/O, сортировку или блокировки.
Если строк в узле сильно больше, чем ожидалось, дальше почти всегда идут лишние nested loop, раздутая память и неожиданные seq scan.

Потом смотрим на признаки боли:
— huge gap между estimated rows и actual rows;
— sort/hash с spill на диск;
— repeated index scan внутри цикла;
— long actual time у узла, который «всего лишь фильтрует».
Схема простая, но дьявол кроется в статистике: плохие оценки обычно лечатся не индексом, а обновлением статистики, переписыванием предиката или разбиением запроса.

И ещё: EXPLAIN ANALYZE сам влияет на выполнение. На боевых запросах это означает лишний оверхед и риск неудачно замерить то, что и так плохо держится под нагрузкой. В продакшене так лучше не делать, и вот почему: для тяжёлых запросов сначала снимайте обычный план, а потом — точечно и под контролем.

Золотое правило: сначала мониторинг, потом индексы. Если план плохой, не спешите «добавить ещё один индекс» — сначала поймите, где сломалась оценка и почему оптимизатор выбрал именно этот путь.