📌 EXPLAIN ANALYZE больше не страшен: 5 паттернов медленных запросов

📌 EXPLAIN ANALYZE больше не страшен: 5 паттернов медленных запросов

Название: Как правильно читать PostgreSQL EXPLAIN ANALYZE Output

Тип: Гайд

Источник: DEV.to

Медленный запрос попал на твоё имя. Ты запускаешь EXPLAIN ANALYZE и видишь стену отступленного текста, которую большинство разработчиков игнорируют. Автор показывает 5 паттернов, которые покрывают подавляющее большинство реальных медленных запросов.

💡 Главные тезисы:

• Запускай EXPLAIN ANALYZE с BUFFERS — так увидишь cache hit rates: EXPLAIN (ANALYZE, BUFFERS) SELECT ....

• Дерево узлов: каждый узел выполняет один шаг запроса. Actual time — реальное время в миллисекундах, умножай на loops для общего времени.

• Ищи узел с наибольшей работой: если родитель занял 48ms, а все дети вместе — 5ms, значит родитель сам потратил 43ms — копаешь туда.

• Seq Scan на большой таблице — читает каждую строку, нормально для маленьких таблиц или когда нужны большинство строк. Проблема при выборке малой доли большой таблицы — фикс обычно индекс.

• Row estimate wildly off: планировщик预估л 10 000 строк, а реально 950 000 — признак устаревшей статистики или skew данных. Фикс: ANALYZE table.

🛠 Чеклист диагностики:

• Sequential scan на большой таблице при выборке малой доли → нужен индекс.

• Row estimate сильно отличается от actual → ANALYZE table для обновления статистики.

• Nested loop с высоким loops count → пропущенный индекс на join-колонке.

• Hash Join vs Merge Join — проверь, какой выбрал планировщик и почему.

• Materialization overhead в подзапросах — попробуй inline-предикаты.

🗣 Цитата: «The node doing the most work is the one with the highest actual time that is not caused by slow children. Compare actual time at each level to find where time is actually consumed.»

🔍 Наш комментарий: Паттерн-подход вместо попытки понять каждый узел — прагматичный способ быстро находить узкие места. Особенно ценно для тех, кто не занимается производительностью PostgreSQL полный день. Подвох: метод работает на 80% случаев, но для сложных запросов с CTE и window functions может потребоваться deeper dive.

#postgresql #database #performance