EXPLAIN ANALYZE не лечит запрос. Он показывает, где больно, если читать его правильно

EXPLAIN ANALYZE не лечит запрос. Он показывает, где больно, если читать его правильно

Коллеги, давайте разберем план выполнения. Главная ошибка — смотреть только на итоговое время и радоваться цифре. Важнее другое: где плану пришлось пройти лишние строки, где сортировка ушла в память, а где — на диск, и какой узел съел основное время.

Сначала ищем разрыв между estimated rows и actual rows. Если оценка ошиблась в разы, оптимизатор строил план на неверной статистике. Дальше смотрим на nested loop, hash join, seq scan, index scan: не «плохой» ли оператор, а оправдан ли он при текущем объеме данных и селективности фильтра.

Посмотрим, что тут с I/O в реальности. Если в плане есть temp read/write, spilled hash, external sort — запрос уперся не в CPU, а в память и параметры работы с буферами. Если один узел показывает 90% времени, а ниже по дереву строки идут быстро, именно он и есть кандидат на переписывание, а не весь запрос целиком.

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