SQL-Ex blog

Как увидеть время компиляции запроса

Если вы хотите увидеть, сколько времени занимает компиляция запроса, у вас есть, насколько мне известно, три варианта. Первый, и, возможно, самый легкий, это посмотреть свойства плана на плане выполнения. Возьмите этот план из запроса SELECT...INTO:



Первый оператор, который выделен, содержит все метаданные о плане. Щелкните правой кнопкой на нем, и выберите “Properties” (свойства) из контекстного меню. Тут вы увидите всю подробную информацию:



Я выделил свойство CompileTime. Вы можете тут также увидеть CompileCPU и CompileMemory. Исходя из этого, вы можете ответить на вопрос о времени (кстати, измеряется в миллисекундах) компиляции запроса. Легко.

Но захват плана выполнения не всегда желателен, а иногда и невозможен. Как еще вы можете получить информацию о компиляции?

SET STATISTICS TIME ON

Это включение статистики запроса приводит к выводу информации такого вида:



Вы можете увидеть время CPU, если есть, и полное время компиляции запроса. Можно увидеть, что этот показатель точен по сравнению с временем компиляции в плане. Да, они не идентичны. Это две разные операции компиляции. Если я продолжу и посмотрю план для второго выполнения, то на этот раз получу те же 3 мс.

Если у вас включено хранилище запросов (Query Store), системное представление sys.query_store_plan даст вам время компиляции, но не время ЦП или памяти.

Как насчет еще одного способа мониторинга времени компиляции запроса. Какое-нибудь из расширенных событий?

Что ж, получилась забавная история. Если вы посмотрите события типа rpc_completed или sql_batch_completed, мы не получим никаких захваченных показателей компиляции. Если посмотреть sql_statement_recompile, хотя мы получаем информацию о перекомпиляции, например о её причине, но не получаем никаких показателей измерения того, сколько времени длилась перекомпиляция. Так что мы немного застряли. Если вы захватите план, используя Extended Events (кстати, очень тяжелый вариант), то можете увидеть время компиляции. Вы могли бы сделать комбинацию событий, rpc_starting наряду с rpc_completed и sql_statement_recompile, используя Causality Tracking для выстраивания их по порядку. Затем просто получите значения времени для события, вычтите время выполнения из общего времени, и вы должны получить число… Ух!

Что еще вы получили?

Отладку?

Расширенные события отладки

Если посмотреть на окно New Session в графическом интерфейсе Extended Events, вы увидите выпадающий список Channel (Я долго попытался сделать снимок экрана с выпадающим списком, но не смог):



Откройте, и увидите список. По умолчанию в этом списке все будет выбрано, за исключением Debug. Это сделано намеренно. Debug Events подвержены изменению, и не обязательно хорошо документированы. Некоторые из них даже представляют опасность. Я рекомендую использовать их с осторожностью.

ОДНАКО

С выходом SQL Server 2017 CU13 мы получили новое событие в категории отладки: sql_statement_post_compile. Это удобное небольшое событие. Посмотрите информацию, которую оно предоставляет:



Мы получаем не только продолжительность (duration) и время ЦП (cpu_time), но также причину перекомпиляции (recompile_cause) и многое другое. На это событие не так много документации. Оно работает хорошо на моих тестах. Если требуется такая информация, я рекомендую использовать это событие.

Заключение

Забавно, как что-то такое простое, как время компиляции, на самом деле может оказаться достаточно сложным. Однако это так. Вы можете получить время компиляции запроса, выбирая между самим планом, statistics_time, Query Store и, если у вас что-то большее, чем 2017 CU13 или Azure, вы можете (легко) воспользоваться Extended Events.