Ответ
Оператор EXPLAIN показывает план выполнения SQL-запроса, который генерирует СУБД. Это основной инструмент для анализа и оптимизации производительности запросов.
Что показывает план выполнения?
- Порядок доступа к таблицам (какая таблица читается первой).
- Используемые индексы (или факт полного сканирования таблицы).
- Типы соединений (JOIN):
NESTED LOOPS,HASH JOIN,MERGE JOIN. - Оценочная стоимость операций и количество строк.
Пример использования:
EXPLAIN SELECT * FROM orders WHERE customer_id = 123;Пример вывода (упрощённо):
-> Index lookup on orders using idx_customer (customer_id=123) (cost=0.35 rows=1)Это означает, что запрос использует индекс idx_customer для эффективного поиска, а не сканирует всю таблицу.
Практическое применение:
- Выявление «узких мест»: Поиск операций с высокой оценочной стоимостью (например,
Full Table Scan). - Проверка использования индексов: Убедиться, что запрос использует созданные индексы.
- Сравнение планов: Оценить, как изменение запроса или добавление индекса повлияет на план.
EXPLAIN ANALYZE (в PostgreSQL, MySQL 8.0+) выполняет запрос фактически и показывает реальное время выполнения и количество строк, что точнее для анализа.
Ответ 18+ 🔞
А, слушай, про эту штуку, EXPLAIN, да? Ну это ж, блядь, как рентген для твоего кривого запроса! Прям светят, сука, и показывают, что у тебя внутри творится, пока база данных мозги ломает.
Что он там, этот ясновидящий, показывает?
- В каком порядке таблицы ебут — кто первым под раздачу попадает.
- Индексы в деле или нет — или она, дура, всю таблицу целиком, как дура, сканировать собралась.
Full Table Scan— это пиздец, чувак, это как искать иголку в стоге сена, перебирая каждую травинку похуй. - Как JOIN'ы склеивает —
NESTED LOOPS,HASH JOIN... Ну, в общем, кто кого ебёт в итоге. - Ну и прикидывает, насколько это всё дорого встанет — стоимость и сколько строк наковыряет.
Смотри, как просто:
EXPLAIN SELECT * FROM orders WHERE customer_id = 123;А он тебе такое выдаст (если ты не мудак и индекс сделал):
-> Index lookup on orders using idx_customer (customer_id=123) (cost=0.35 rows=1)Вот видишь? Красота! Он не по всей таблице, сука, скакал, а сразу по индексу прыг-скок — и нашёл. cost=0.35 — это вообще копейки, ебать мои старые костыли!
А нахуя это всё?
- Найти, где тормозит. Увидел в выводе
Full Table Scanна таблице в миллион строк — всё, пизда. Сиди, думай, как исправить. - Проверить, индексы работают или просто так висят. А то создашь ты их, овердохуища, а запрос как ходил в жопу, так и ходит.
- Сравнить, стало ли лучше. Изменил запрос или индекс новый прикрутил — запусти
EXPLAINдо и после. Если стоимость упала — красава. Если выросла — ну ты и мудак.
А есть же ещё EXPLAIN ANALYZE (в Постгре и новых MySQL)! Вот это вообще жёстко. Он запрос реально выполняет, блядь, и потом говорит: «Вот, смотри, я там нахуярился, и это заняло столько-то миллисекунд, а не как я в прошлый раз прикидывал». Правдивее, конечно, но если запрос и так долгий, то придётся ждать, пока он всё проанализирует. Терпения ноль ебать, но зато точность — пиздец.