Что можно увидеть в EXPLAIN кроме времени выполнения

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

Понимаете ли вы, что происходит с вашим запросом после того, как Hibernate отправил его в базу. Вопрос обычно возникает вокруг медленного эндпоинта, и по ответу видно, читали ли вы планы сами или только слышали про индексы.

Как отвечать

Сначала снимите неточность вопроса: обычный EXPLAIN времени не показывает. Он печатает план, выбранный планировщиком по статистике, вместе с оценками. Замеры даёт EXPLAIN ANALYZE, который запрос действительно выполняет.

Что читается в плане:

• способ доступа к таблице: последовательное чтение, обычный или покрывающий индексный доступ, чтение по битовой карте: видно, взялся ли индекс и какой;
• алгоритм соединения: вложенные циклы, хеш-соединение, слияние, а также порядок, в котором таблицы соединяются;
• оценки: ожидаемое число строк, ширина строки, стоимость в условных единицах;
• в режиме с замером: фактическое число строк, число повторов узла, а с опцией BUFFERS сколько блоков пришло с диска, а сколько из кэша;
• служебные узлы: сортировка с пометкой, уместилась ли она в память, агрегация, материализация, сбор параллельных результатов;
• фильтрация: условие внутри индексного доступа против фильтра поверх прочитанного, с числом отброшенных строк.

Главная ценность плана это расхождение оценки и факта. Ждали десяток строк, получили сотни тысяч, значит дело в статистике или в коррелированных условиях, а не в индексе. В MySQL то же самое подано колонками: тип доступа, ключ, оценка строк, примечания.

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

Называют типом соединения то, что написано в самом запросе. В плане речь о физическом алгоритме, а не о внешнем или внутреннем соединении: логику видно в тексте SQL, читать её из плана незачем.

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

Третье: разбирают идеальный план одного запроса и не замечают, что запросов тысяча. Ленивая загрузка коллекции даёт лавину запросов, где каждый план безупречен, а эндпоинт отвечает секунды.