Как понять время, потраченное на каждый шаг в плане выполнения?

Question

Я использую SQL Server Execution plan для анализа времени выполнения оператора SQL. Но я не могу понять время, потраченное на каждый шаг в результате плана. Похоже, что результат не имеет смысла для меня.

В моем запросе я включил следующие параметры:

SET STATISTICS TIME ON
SET STATISTICS PROFILE ON

, и я запускаю план выполнения с включенным Actual Execution Plan,Ниже приведен скриншот:

На диаграмме плана перечислены некоторые шаги, и я могу увидеть время выполнения каждого шага, щелкнув их и прочитавActual Time Statistics на правой панели свойств, как показано ниже:

И в выводе сообщения я вижу общее время для моего запроса:

SQL Server Execution Times:
   CPU time = 47 ms,  elapsed time = 331 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

Вы можете видеть, что это занимает в общей сложности 331 мс, но время, затрачиваемое на каждый шаг, очень мало, наибольшее из которых составляет 14 мс, а большинство других равно 0. Общее время, прошедшее от результата плана выполнения, намного меньше, чемвсего 331мс. Как я могу понять время истечения? Без этого я не могу понять, какое узкое место в моем заявлении sql

Answer 1

Execution Time: общее время, необходимое серверу Sql для завершения выполнения плана компиляции.

CPU Time: фактическое время, потраченное на CPU. Если CPU time равно 0, это означает, что запрос поступает напрямую изcache plan. Если запрос compiling и recompiling, тогда загрузка процессора и CPU time будут больше. Существуют и другие факторы, которые влияют на процессорное время.

Elapse Time: общее время, необходимое для завершения анализа и компиляции, включая время, необходимое для получения результата клиенту.

Оба важны дляпонять. Если я хочу, чтобы показ результата клиенту в короткие сроки был очень важен, тогда я могу проигнорировать CPU time. Так что в этом случае Elapse time важнее, чем CPU Time.

В другом случае я могу проигнорировать немного большее Elapse time и сконцентрироваться на снижении высокого CPU time.

Безчто я не могу понять, какое узкое место в моем выражении sql

Execution Time(CPU+Elapse) само по себе не является узким местом. Это всего лишь показатель. Если это нежелательно, тогда вам нужно выяснить, какое operator является узким местом, и предпринять соответствующие действия.

Как написать optimize query или Index Tune или изменить схему таблицы или какую-то другую вещь.

Согласно вашему тарифному плану Hash Match считается самым дорогим оператором. Ваш основной запрос не отображается.

Вы также можете посмотреть, что Время ожидания

, почему общее время, проведенное в каждом плане, намного меньше, чем затраченное времясообщается из окна вывода сообщения, которое составляет 331 мс?

Предположим, у вас очень простой запрос, например,

Select * from Person.Person

В этом случае каждый оператор начинает выполнение после своего правого операторапрекратил выполнениеВ таком сценарии, теоретически говоря,

Total Elapse Time is sum of each operator Elapse Time.

Если запрос выполняется непосредственно из плана запроса или время Elapse слишком мало, то оно округляется до 0. Но теоретически, Total Elapse Time is sum of each operator Elapse Time.

Сейчасвозьмите любой сложный запрос, как в вашем примере, один или несколько операторов начинают выполняться одновременно, а затем объединяются в один, конечное время истечения может быть другим.

Ваш основной план запроса не полностью виден, иначе я бы попытался объяснить, чтоЯ имею в виду.

Если вы используете Sql server 2016 или выше, вы можете посмотреть, как данные передаются и как работают несколько операторов.

Статистика запросов в реальном времени

Статистика активных запросов

Даже если у вас нет Sql server 2016, вы все равно можете понять реальный вопрос.