我正在使用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 is,但每一步所花费的时间非常少,其中最多的一步是14 is,而其他步骤的大部分时间是0。从执行计划结果到执行计划结果的总时间远远小于总共331 is。我如何理解逝去的时间?没有这一点,我就无法弄清楚sql语句中的瓶颈是什么
发布于 2019-10-03 05:09:29
Execution Time:Sql server完成编译计划执行所需的总时间。
CPU Time:用于CPU.If CPU time的实际时间为0,这意味着查询直接从cache plan获取。如果查询是compiling和recompiling,那么将有更多的CPU使用和CPU time。还有其他影响CPU时间的因素。
Elapse Time:完成解析和编译所需的总时间,包括将结果带到客户端所需的时间。
这两者对understand.If都很重要,我希望在短时间内向客户显示结果是非常重要的,所以我可以忽略CPU time。因此,在这种情况下,Elapse time比CPU Time更重要。
在其他情况下,我可以忽略较高的Elapse time,集中精力减少高CPU time。
没有这一点,我就无法弄清楚sql语句中的瓶颈是什么
Execution Time(CPU+Elapse)本身并不是一个bottleneck.It,它只是一个指示器。这是不可取的,然后你必须调查哪个operator是瓶颈,并采取适当的行动。
比如编写optimize query或Index Tune,或者更改表模式或其他一些东西。
根据您的查询计划,Hash Match被认为是最昂贵的操作符。您的主要查询不可见。
你也可以看到等待时间
为什么每个计划所花费的总时间远远少于从消息输出窗口报告的时间,即331 is?
假设您有非常简单的查询,
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。
现在,以任何复杂的查询为例,一个或多个操作符开始同时执行,然后合并为一个,最后的Elapse时间可能不同。
您的主要查询计划不是完全可见的,否则我会尝试解释我的意思。
如果您正在使用Sql server 2016或更高版本,那么您可以查看数据是如何流动的,以及多个操作符是如何协同工作的。
即使您没有Sql server 2016,您仍然可以理解实际情况。
https://stackoverflow.com/questions/58211495
复制相似问题