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

Давай разберемся, что это за зверь такой — план выполнения запроса. Представь, что ты дал SQL-серверу задание: «Эй, приятель, найди мне все заказы дороже тысячи баксов». А он, вместо того чтобы сразу нырнуть в таблицу, сначала садится и чертит на салфетке пошаговый план, как он это будет делать. Вот эта салфетка с каракулями — и есть план выполнения. И иногда там такой пиздец нарисован, что волосы дыбом встают.

И что же на этой салфетке намалевано?

• Кого бить первым: В каком порядке он будет шастать по таблицам, когда делает JOIN. Иногда начинает с самой большой, а потом охуевает от количества данных.
• Как искать: Будет ли он умно пользоваться индексом (как по алфавитному указателю в книге) или просто начнёт тупо сканировать всю таблицу с первой до последней страницы, что на больших объёмах — пиздец как долго.
• Какие трюки выкинет: Будет ли фильтровать, сортировать, клеить таблицы через хэши или вложенные циклы.
• Оценка затрат: Рядом с каждой операцией он пишет, насколько она, по его мнению, дорогая. Ищешь операцию с ценником в 80% — вот тебе и узкое место, скорее всего.
• Оценка рядов: Сколько строк он ожидает найти на каждом шаге. А вот когда реальное число в десять раз больше ожидаемого — вот тут и начинается веселье, оптимизатор ебёт сам себя по мозгам.

Зачем тебе, собственно, в это всё вникать? Потому что когда запрос тормозит как черепаха в патоках, а ты не смотришь план — ты как слепой котёнок, который тыкается мордой в проблему. План — это твой рентгеновский аппарат. Он покажет:

1. Где конкретно затык: Видишь жирную надпись Table Scan на таблице в миллион строк? Ну всё, приехали. Надо индекс делать.
2. Работают ли твои индексы: Может, ты их создал, а запрос про них благополучно забыл и сканирует всё подряд.
3. Чего не хватает: Умные СУБД иногда прямо в плане пишут: «Чувак, не хватает индекса вот с такими-то полями, добавь — будет тебе счастье».
4. Почему всё так долго: Может, он из-за кривой статистики решил, что строк будет 100, а их оказалось 100000, и выбрал идиотский алгоритм соединения. В плане это видно.

Как эту салфетку-план выцарапать из сервера?

• В SQL Server Management Studio (SSMS): Самый простой способ — перед запросом написать SET STATISTICS XML ON;, выполнить его, и тебе вывалится красивая XML-ка. Или просто нажать Ctrl+M, а потом выполнить запрос — графический план увидишь. Это как разобрать двигатель и посмотреть на каждую шестерёнку.
• Если пишешь на C# / Entity Framework Core: Тут немного посложнее, потому что EF сама генерирует SQL. Но вытащить его можно и посмотреть план отдельно.

  using (var context = new MyDbContext())
  {
  var query = context.Orders.Where(o => o.Total > 1000);
  // Вытаскиваем SQL, который EF сгенерировала
  var sql = query.ToQueryString();
  Console.WriteLine(sql); // Копируем эту строку и лезем с ней в SSMS
  }

На какие слова в плане сразу орать «Ёбаный рот!»?

• Table Scan / Index Scan: Полное сканирование. Если таблица большая — это пиздец, а не операция.
• Index Seek: А вот это хорошо. Умный поиск по индексу.
• Key Lookup (он же Bookmark Lookup): Это когда он нашёл запись по индексу, но ему нужны ещё какие-то поля, которых в индексе нет. И он пошёл искать их в основной таблице. Для каждой строчки. Если таких строчек тысячи — производительность летит в тартарары. Лечится покрывающим индексом (добавить поля в INCLUDE).
• Sort: Сортировка. Если данных много, а памяти мало — будет больно.
• Spill to TempDB: Вот это вообще апофеоз. Когда операция (чаще всего хэш-соединение) не влезает в оперативку и начинает срать на диск, в TempDB. Скорость падает ниже плинтуса.

Главный лайфхак: Всегда смотри фактический план выполнения (тот, что строится уже после того, как запрос отработал), а не просто расчётный. Потому что в фактическом плане будут реальные цифры: сколько строк на самом деле обработалось, сколько времени ушло. А в расчётном — только догадки оптимизатора, которые могут быть хуёвыми.