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

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

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

Смотрите не только на общий time. Важнее: — где растет разница между planned rows и actual rows; — какие узлы дают много loops; — есть ли Seq Scan там, где ожидали Index Scan; — не съедает ли Nested Loop огромный внутренний объем. Схема простая, но дьявол кроется в статистике.

Посмотрим, что тут с I/O в реальности. Если в плане высокий time, но мало actual rows, ищите блокировки, холодный кэш, сортировки на диск и лишние передачи данных между узлами. Если узел «дорогой» только на бумаге, а по факту дешёвый — не спешите менять индекс: сначала проверьте селективность условий и актуальность статистики.

Не лечите верхний узел, пока не нашли источник перекоса ниже по дереву. Обычно полезнее всего открыть самый медленный подузел, понять, почему он стал таким, и уже потом решать: переписать запрос, обновить статистику или добавить индекс. Золотое правило: сначала мониторинг, потом индексы.