Что такое план запроса и как его посмотреть

Что проверяют

Умеет ли Java-разработчик разбираться с медленным SQL, а не только его писать. За вопросом стоит понимание, что способ исполнения выбирает не автор запроса, а планировщик СУБД, и это решение можно посмотреть и объяснить.

Отдельно смотрят, снимаете ли вы план с реального запроса: в приложении на JPA текст SQL генерирует ORM, и то, что видно в коде, регулярно расходится с тем, что уходит в базу.

Как отвечать

План запроса это дерево операций, выбранное планировщиком: способ доступа к каждой таблице (последовательное чтение или обращение по индексу), порядок и алгоритм соединений, сортировки и агрегации. Выбор делается по оценке стоимости на основе собранной статистики.

EXPLAIN (ANALYZE, BUFFERS) SELECT ...;

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

В MySQL есть EXPLAIN и, в современных версиях, EXPLAIN ANALYZE. В Oracle фактический план снимают через DBMS_XPLAN по курсору, а не только через EXPLAIN PLAN.

Что искать в выводе: узел с наибольшим собственным временем, чтение всей большой таблицы под селективным фильтром, вложенный цикл с огромным числом повторов, сортировку, ушедшую на диск.

Где спотыкаются

Забывают, что EXPLAIN ANALYZE действительно выполняет запрос, включая UPDATE и DELETE. На боевой базе такой замер делают внутри транзакции с последующим откатом.

Снимают план с запроса, где значения подставлены прямо в текст, а приложение отправляет подготовленный запрос с параметрами. Планы у них могут отличаться, и оптимизируется не то, что тормозит в проде.

Читают только верхнюю строчку с итоговой стоимостью. Cost это условные единицы планировщика, а не миллисекунды, и сравнивать его можно лишь между вариантами одного запроса на одной базе.