Читаем EXPLAIN: где запрос теряет время

Сохраните исходные условия

Зафиксируйте SQL, параметры, версию PostgreSQL и объём данных. Один запрос с разными значениями параметров может работать по-разному. Повторяйте измерения в сопоставимых условиях, учитывая прогрев кэша и параллельную нагрузку.

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

Получите фактический план

Пример использует условную таблицу заказов. Подставьте свой запрос и проверьте влияние выполнения на окружение.

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, created_at
FROM orders
WHERE account_id = 42
ORDER BY created_at DESC
LIMIT 50;

Читайте дерево от дочерних узлов к родительским. cost — оценка в условных единицах, а не миллисекунды. Фактические времена и количество строк смотрите в части actual.

Ищите расхождения, а не страшные названия

• Большое отличие оценочного числа строк от фактического может указывать на проблемы статистики или сложную зависимость условий.
• При нескольких loops фактические строки и время узла показываются в среднем за выполнение. Учитывайте число повторов.
• Rows Removed by Filter помогает увидеть, сколько строк прочитано и отброшено.
• Данные BUFFERS показывают работу с буферами; чтение блока не всегда означает физическое чтение с диска.

Последовательное сканирование само по себе не ошибка. На небольшой таблице или при чтении значительной доли строк оно может быть разумным выбором.

Меняйте одну вещь за раз

Проверьте актуальность статистики, затем форму запроса и подходящие индексы. После изменения сравните план, время и объём прочитанной информации на тех же параметрах. У индекса есть цена: место и дополнительная работа при записи.