EXPLAIN в PostgreSQL показывает план, выбранный для запроса. EXPLAIN ANALYZE дополнительно выполняет запрос и сообщает наблюдения выполнения. На Mentoring.digital разберём безопасный порядок первого чтения плана: что является оценкой, где искать расхождение и почему один Seq Scan ещё не означает проблему.
Начните с обычного EXPLAIN
EXPLAIN
SELECT id, created_at
FROM orders
WHERE customer_id = 42;Здесь orders является условной таблицей приложения, а 42 учебным значением. Команда не создаёт таблицу и не подготавливает данные. Для собственного разбора нужны реальная структура, индексы, условия фильтра и контекст запроса. План без этих сведений легко трактовать неверно.
Читайте дерево от источников данных к операциям над ними. Сначала определите способ чтения, затем фильтрацию, соединения, сортировку и итог. Не начинайте с поиска самого большого числа без понимания, к какому узлу оно относится. Один узел может описывать работу над результатом другого, поэтому простое сложение показателей не является готовым измерением времени.
Оценка стоимости не равна миллисекундам
Планировщик использует оценки стоимости и числа строк. Это сведения о выбранной модели выполнения, а не результат секундомера. Для диагностики полезно отметить, сколько строк предполагается получить на важном этапе и какой способ доступа выбран.
Сам по себе последовательный просмотр не доказывает отсутствие нужного индекса. Для небольшой таблицы или большой доли подходящих строк такой вариант может быть разумным. Сначала выясните, какую долю данных запрашивает операция и насколько достоверны наблюдения о её задержке. Принудительное изменение плана без этих сведений может усложнить ситуацию.
ANALYZE выполняет запрос
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, created_at
FROM orders
WHERE customer_id = 42;Даже SELECT может оказаться тяжёлым. Запускайте такой разбор в согласованной среде и учитывайте допустимую нагрузку. Для изменяющих запросов особенно важно понимать побочные эффекты: слово EXPLAIN не делает UPDATE или DELETE безопасной демонстрацией, если указан ANALYZE. Здесь мы не выполняли запросы на рабочей базе сайта.
Параметр BUFFERS добавляет сведения о работе с буферами. Они помогают обсуждать характер чтения, но не заменяют контекст окружения. Не сравнивайте без оговорок первый холодный запуск с повторным, когда часть данных уже доступна в памяти. Изменение условий может объяснять разницу и без полезной правки запроса.
Ищите место расхождения, затем причину
Сопоставьте оценённые и фактические строки на интересующем узле, учитывая число повторений. Если расхождение заметно, это основание исследовать данные и статистики, а не доказательство одной конкретной причины. Условия с коррелированными полями и неравномерные значения могут требовать отдельного анализа.
Сохраните текст запроса, его параметры, схему, индексы, версию PostgreSQL и план. Для сравнения двух вариантов используйте одинаковый набор условий и подтверждайте одинаковый результат. Ускорение ценой потери нужных строк является изменением смысла операции, а не чистой оптимизацией.
Что передать на разбор
Подготовьте обезличенную структуру и план, ожидаемое число результатов и описание задержки. Не отправляйте персональные данные и полный дамп, если для вопроса достаточно ограниченного примера. Отметьте, что измерено фактически и что пока предполагается.
Набор чисел плана здесь намеренно не выдуман: без базы и выполнения он был бы декоративным. Для предметного чтения собственного плана можно выбрать ментора по PostgreSQL. Начальная цель проста: объяснить путь данных и выбрать следующую проверку, а не обещать ускорение на произвольный процент.
