EXPLAIN ANALYZE: где план ломает ожидания и как это поймать без магии

EXPLAIN ANALYZE: где план ломает ожидания и как это поймать без магии

Коллеги, давайте разберем план выполнения. Сам EXPLAIN показывает, что оптимизатор собрался делать, а ANALYZE — что он реально сделал. И вот тут часто всплывает разница между красивым планом и тяжелым продом: оценки строк мимо, сортировка в память не влезла, nested loop внезапно обошелся дороже seq scan.

Смотрите на три вещи:
— estimated rows vs actual rows: если разрыв в разы, статистика врет или условие плохо селективно;
— loops: высокий loop-count быстро превращает «нормальный» оператор в пожирателя CPU;
— time vs rows: узкое место может быть не в самом операторе, а в дочернем узле, который его кормит.

Дальше — I/O и память. Если видите temp files, spills, большие shared read, не лечите это сразу индексом. Сначала поймите, почему план выбрал именно такой путь: не хватает статистики, неудачный порядок JOIN, слишком широкий набор колонок, или запрос тянет лишнее через SELECT *. Схема простая, но дьявол кроется в статистике.

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