Что такое план выполнения запроса (execution plan) в SQL?

А, ну так, слушай, про эти ваши «план-е-выполнения-запроса»… Это ж такая штука, блядь, которую база данных, эта сука, на коленке рисует, когда ты ей свой SQL-запрос подсовываешь. Представь, ты ей: «Дай мне всё, где customer_id = 123». А она, эта мартышлюшка, вместо того чтобы сразу впердолить, начинает думать: «Э-э-э, бошка думай… Как бы мне так сделать, чтобы не обосраться и не перелопатить всю таблицу, если можно по быстрому?»

И вот она, блядь, этот самый план и строит. Как маршрут для идиота. «Сначала пойди туда, потом посмотри сюда, потом соедини это вот так, а потом отфильтруй».

Ну и из чего этот план, спрашивается, состоит, блядь?

• Как данные искать будем? Или вот так, с разбегу, всю таблицу (Seq Scan) просканируем, как последние дебилы — это если индекса нет, ёпта. Или же по-умному, по индексу пройдёмся (Index Scan), если, конечно, этот самый индекс мы, не мудаки, заранее создали.
• А как таблицы между собой склеивать, если JOIN? Тут, бля, целый театр, ёперный театр! Можно вложенными циклами (Nested Loop) — для мелких дел. Можно хешами накидать (Hash Join) — когда данных овердохуища. А можно и слиянием (Merge Join) — если всё по порядку.
• Ну и всякая другая хуйня: фильтрация, сортировка, агрегация — «посчитай мне сумму, блядь».
• И самое главное — оценочная стоимость (cost)! Это типа как база думает: «На эту операцию я, сука, потрачу условных 5 центов, а на эту — 500 долларов». И складывает, чтобы выбрать самый дешёвый план, хитрая жопа.

Ну и как на это всё посмотреть, спросишь ты? Да элементарно, ваще!

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 123;

Ты это выполнишь, и она тебе, блядь, не просто результат выплюнет, а целый отчёт: «Я, мол, вот так делала, потратила столько-то времени, просканировала столько-то строк». ANALYZE — это чтобы она не просто нарисовала план, а реально выполнила запрос и сказала, где она, сука, обосралась по времени.

И зачем это всё, блядь, нужно? Да затем, чувак!

1. Узкие места найти. Смотришь на план, а там Seq Scan на миллион строк. И сразу ясно: «Ах ты, пизда с ушами! Индекса-то нет!» Волнение ебать, терпения ноль.
2. Проверить, работают ли индексы. Создал ты индекс, а он, гад, его не использует. Значит, либо индекс кривой, либо запрос написан так, что ему проще по всей таблице пройтись.
3. Сравнить два запроса. Один написал с подзапросом, другой с JOIN. Запустил EXPLAIN на оба — и сразу видно, какой из них реально быстрее, а какой просто выёбывается.

Короче, пиздец как важно. Если у тебя запрос тормозит как хуй в пальто, первым делом лезешь смотреть его план выполнения. Это как рентген для твоего SQL — сразу все кости, все проблемные места видны. Без этого — ты просто тыкаешь пальцем в небо, надеясь, что само рассосётся. А оно не рассасывается, блядь.