Ответ.

История вопроса:
С самого начала SQL-запросы проектировались как декларативные: «что получить», а не «как получить». Оптимизатор СУБД строит план выполнения (execution plan), который определяет очередность соединений, фильтраций, сканирований и использования индексов.

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

Решение:
Инструменты анализа — это инструкции типа EXPLAIN, EXPLAIN ANALYZE (PostgreSQL), SHOW EXPLAIN (MySQL), Management Studio Execution Plan (SQL Server). С их помощью можно увидеть пошагово, как именно выполнился запрос, какой объём данных прочитан, какой из индексов был использован, где происходили сканирования таблицы целиком (table scan), и где возникли задержки.

Пример кода:

EXPLAIN ANALYZE SELECT * FROM orders o JOIN customers c ON o.customer_id = c.id WHERE o.status = 'shipped';

Ключевые особенности:

• План даст подробную схему, какую операцию в каком порядке выполнила СУБД.
• Можно увидеть, где использован index scan, а где — table scan.
• Позволяет выявлять узкие места для оптимизации и проверки гипотезы о влиянии переписывания запроса на производительность.

Вопросы с подвохом.

Если добавить индекс, запрос всегда ускорится?

Нет! Индекс поможет только если фильтрация по его полю значительно ограничивает число возвращаемых строк. Если большинство записей подходят под условие, оптимизатор может проигнорировать индекс.

Пример:

-- Поле 'gender' принимает всего два значения — индекс не поможет
CREATE INDEX idx_gender ON people(gender);
SELECT * FROM people WHERE gender = 'M';

Зависит ли порядок таблиц в JOIN от результата выполнения?

Нет, итоговые данные будут одинаковы, однако оптимизатор может переставить порядок выполнения соединений для повышения производительности. Но если написан специфический JOIN или используются подсказки типа "JOIN HINT", порядок может повлиять на эффективность выполнения.

Зачем анализировать "Estimated rows" и "Actual rows" в плане выполнения?

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

-- PostgreSQL
ANALYZE table_name; -- обновить статистику

Типовые ошибки и анти-паттерны

• Не просматривается execution plan при возникновении проблем: пытаются оптимизировать "вслепую"
• Добавление лишних/нецелевых индексов для "ускорения", что только тормозит изменения данных
• Не обновляется статистика по таблицам
• Запросы проектируются без учёта того, как их будет исполнять оптимизатор

Пример из жизни

Негативный кейс

На проекте аналитики долго жаловались на "зависание" отчётов. Запрос с пятью JOIN'ами выполнялся 25 минут. Оказалось, что был выбран plan с полным сканированием огромной таблицы вместо index scan, индексы были не по тем полям, и статистика год не обновлялась.

Плюсы:

• Простая поддержка, минимизация индексов

Минусы:

• Запрос работал медленно, тратились часы человеческого труда
• Недовольство пользователей
• Нагрузка на сервер

Позитивный кейс

Провели анализ execution plan, добавили индекс по реально фильтрующему полю, обновили статистику. Время запроса уменьшилось до 20 секунд. Загрузку на сервер снизили на порядок.

Плюсы:

• Быстрый отклик
• Снижение износа оборудования

Минусы:

• Часть запросов после оптимизации требует пересмотра кода
• Риски избыточных индексов для OLTP-сценариев