EXPLAIN и анализ плана выполнения запроса

Когда аналитик сталкивается с медленным запросом, первый вопрос — почему он медленный? EXPLAIN — это команда, которая показывает план выполнения запроса: как именно СУБД будет искать и обрабатывать данные. Это рентген вашего SQL-запроса, позволяющий увидеть узкие места до того, как запрос выполнится на миллионах строк.

Как работает EXPLAIN

Добавьте EXPLAIN перед любым SELECT-запросом, и СУБД вернет не результат, а план выполнения — последовательность операций, которые она планирует выполнить. В PostgreSQL для более детальной информации используйте EXPLAIN ANALYZE, который не только покажет план, но и выполнит запрос, добавив реальное время выполнения каждого шага.

EXPLAIN ANALYZE
SELECT u.user_id, u.name, COUNT(o.order_id) AS order_count
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id
WHERE u.registration_date >= '2024-01-01'
GROUP BY u.user_id, u.name;

Результат будет содержать строки вроде:

Seq Scan on users u  (cost=0.00..1543.00 rows=5000 width=64) (actual time=0.023..12.456 rows=4823 loops=1)
  Filter: (registration_date >= '2024-01-01'::date)
Hash Join  (cost=245.00..3421.50 rows=15000 width=72) (actual time=5.234..45.123 rows=12456 loops=1)

Ключевые элементы плана выполнения

Типы сканирования таблиц: - Seq Scan (Sequential Scan) — последовательное чтение всей таблицы построчно. Это самый медленный способ для больших таблиц. Если вы видите Seq Scan на таблице с миллионами строк в условии WHERE по конкретному полю — это красный флаг. - Index Scan — использование индекса для быстрого поиска нужных строк. Значительно быстрее для выборочного чтения. - Index Only Scan — все необходимые данные берутся из индекса без обращения к таблице. Самый быстрый вариант.

Стоимость операций (cost): Числа в формате cost=0.00..1543.00 показывают оценочную стоимость операции. Первое число — стоимость до получения первой строки, второе — до получения всех строк. Это относительные единицы, не секунды. Сравнивайте стоимости разных частей запроса между собой: если один JOIN стоит 50000, а другой 500 — проблема в первом.

Количество строк (rows): rows=5000 — сколько строк СУБД ожидает обработать на этом шаге. Если оценка сильно расходится с реальностью (видно в actual rows=... при EXPLAIN ANALYZE), статистика таблицы устарела — нужен ANALYZE table_name.

Поиск узких мест на практике

Проблема 1: Полное сканирование большой таблицы

EXPLAIN
SELECT * FROM orders WHERE customer_id = 12345;
-- Результат: Seq Scan on orders (cost=0.00..45000.00 rows=1)

При 10 миллионах строк в таблице orders СУБД читает всю таблицу ради одной записи. Решение: индекс на customer_id.

Проблема 2: Неэффективный JOIN

EXPLAIN ANALYZE
SELECT o.*, p.product_name
FROM orders o
JOIN products p ON o.product_id = p.product_id
WHERE o.order_date >= '2024-01-01';

Если план показывает Hash Join (cost=150000.00...) с огромной стоимостью, возможно: - Фильтр по order_date применяется после JOIN, а не до - Отсутствует индекс на product_id в одной из таблиц - Таблицы соединяются в неоптимальном порядке

Проблема 3: Избыточная сортировка Если видите Sort (cost=25000.00..27000.00) с большой стоимостью, а сортировка не нужна для бизнес-логики — уберите ORDER BY или используйте индекс, который уже хранит данные в нужном порядке.

Практический алгоритм анализа

1. Запустите EXPLAIN ANALYZE на медленном запросе
2. Найдите операции с наибольшей стоимостью (cost) и временем выполнения (actual time)
3. Проверьте типы сканирования: есть ли Seq Scan там, где должен быть Index Scan?
4. Оцените количество обрабатываемых строк: не обрабатывается ли миллион строк там, где нужно 100?
5. Посмотрите на порядок JOIN: не соединяются ли сначала большие таблицы без фильтрации?

Ключевой вывод: EXPLAIN превращает оптимизацию из гадания в инженерный процесс. Вместо случайных попыток ускорить запрос вы видите точные места, где теряется время, и можете целенаправленно их исправить — добавить индекс, изменить порядок JOIN или переписать условия фильтрации.