Ответ
В SQL Server Management Studio (SSMS) есть несколько основных способов:
1. Графический план выполнения (наиболее наглядный):
- Предполагаемый план (Estimated): Нажимаю
Ctrl+Lили кнопку "Display Estimated Execution Plan". Запрос не выполняется, план строится на основе статистики. - Фактический план (Actual): Включаю кнопку "Include Actual Execution Plan" (
Ctrl+M), затем выполняю запрос. Во вкладке Execution plan отобразится реальный план с метриками времени и количества строк.
2. Текстовый/XML план:
- Можно получить план в формате XML для детального анализа или сравнения.
SET STATISTICS XML ON; GO SELECT * FROM Sales.Orders WHERE OrderDate > '2023-01-01'; GO SET STATISTICS XML OFF;
На что смотрю в плане (сверху вниз, справа налево):
- Стоимость операций (Relative Cost %): Выявляю наиболее дорогие узлы (жирные стрелки).
- Тип доступа к данным: Index Seek (хорошо) vs Index/Table Scan (плохо, если таблица большая).
- Key Lookup (RID Lookup): Указывает на недостающий покрывающий индекс.
- Предупреждения: Жёлтые значки — например, "Missing Index", "Implicit Conversion".
- Фактические vs Оцененные числа строк: Большое расхождение говорит о устаревшей статистике.
- Дорогие операции:
Sort,Hash Match(Join/Aggregate),Spool.
Для анализа исторических проблем использую системные представления: sys.dm_exec_query_stats и sys.dm_exec_query_plan.
Ответ 18+ 🔞
А, ну это же классика, блядь! Смотри, в SSMS есть несколько способов посмотреть, как твой запрос собирается на коленке собирать. Главное — не упасть в обморок, когда увидишь, что он там вытворяет.
1. Графический план (самое наглядное говно):
- План понарошку (Estimated): Жмёшь
Ctrl+L. Запрос не запускается, а тебе показывают фантазии оптимизатора на основе статистики, которая могла помереть три года назад. Как смотреть гороскоп — веришь, но не до конца. - Настоящий, в говне и крови план (Actual): Включаешь кнопку "Include Actual Execution Plan" (
Ctrl+M), а потом уже запускаешь запрос. Вот тут-то и начинается цирк. Во вкладке Execution plan покажут, что было на самом деле: сколько времени ебалась каждая операция и сколько строк по факту прошло.
2. План в виде текста или XML (для мазохистов и автоматизации):
- Если хочешь поковыряться в кишках или сравнить два плана, можно вытащить его как XML.
SET STATISTICS XML ON; GO SELECT * FROM Sales.Orders WHERE OrderDate > '2023-01-01'; GO SET STATISTICS XML OFF;
А теперь, на что смотреть в этой картиночке, чтобы не облажаться: Смотришь сверху вниз и справа налево, как будто книжку на иврите читаешь.
- Вес операций (Relative Cost %): Ищешь самые жирные стрелки. Вот этот узел, который 70% всей хуйни съедает — он и есть твой враг.
- Как лезет в данные: Index Seek — молодец, пошёл по нужному индексу. Index/Table Scan — обосрался, читает всё подряд, как угарелый. Для большой таблицы — это пиздец, а не операция.
- Key Lookup (он же RID Lookup): Это тебе прямо намёк, что индекс не покрывающий. Сервер находит запись в индексе, а потом идёт по каждой хуйне отдельно в саму таблицу, как дурак. Теряет время, как последний распиздяй.
- Жёлтые иконки-предупреждения: Внимание, ёпта! Если видишь жёлтый треугольник с восклицательным знаком — это "Missing Index" или "Implicit Conversion". Игнорируешь — сам потом будешь плакать.
- Цифры "Фактические vs Ожидаемые строки": Если оптимизатор ожидал 10 строк, а по факту их 100 000 — у тебя статистика хуёвая, и он составил план, как слепой котёнок. Расхождение в разы — уже повод волосы на жопе рвать.
- Дорогие операции-пожиратели:
Sort(сортировка),Hash Match(для соединений или агрегации),Spool(временные результаты). Если они появляются на больших данных — готовься к долгой, долгой песне.
А если тебе нужно понять, что там творилось в прошлом, пока ты спал, лезь в системные представления: sys.dm_exec_query_stats и sys.dm_exec_query_plan. Там, бывает, такие планы лежат, что диву даёшься, как система вообще ещё жива.
