SQLServer的收集统计和分析语句的运行

除了执行计划本身之外，还有其他因素需要考虑，例如语句编译时间、执行时间和磁盘读取次数。

如果DBA可以分别测试问题语句，则可以在运行之前打开以下三个开关，并收集语句运行的统计信息。
这些信息对分析这个问题很有价值。
复制代码代码如下所示：
设置统计时间
设置统计数据
设置统计配置文件

设置统计时间
--------------------------------------------------------------------------------
请看一下将返回什么设置统计时间：
复制代码代码如下所示：
DBCC dropcleanbuffers
-清除缓冲池中的所有缓存数据
DBCC freeproccache
去
-清除缓冲池中所有缓存的执行计划
设置统计时间
去
使用AdventureWorks } {
去
选择不同的（{ }，{ UnitPrice } ProductID）从{ } { } salesorderdetail_test dbo。
在{ ProductID } = 777
去
设置统计时间
去

除了结果集，SQLServer返回以下两段信息
复制代码代码如下所示：
sql服务器分析和编译时间：
CPU时间= 15毫秒，占用时间= 104毫秒。
sql服务器分析和编译时间：
CPU时间= 0毫秒，占用时间= 0毫秒。
（4行受影响）
SQLServer执行时间：
CPU时间= 171毫秒，占用时间= 1903毫秒。
sql服务器分析和编译时间：
CPU时间= 0毫秒，占用时间= 0毫秒。

众所周知，SQLServer执行语句分为以下几个阶段：分析编译执行
根据表的统计信息，分析适当的执行计划，然后编译语句，并在结束时执行语句。

现在，上面的输出是什么意思：
--------------------------------------------------------------------------------
1、CPU时间：这个值的含义是指在这一步的SQLServer纯CPU时间是什么，有多少CPU资源用在声明
2。占用时间：这个值是指这个步骤需要多少时间，也就是说，这是一个句子运行的时间。一些行动将在我/ O操作，致使我 / O等待，或阻塞和阻塞等待。总之，时间已经失去，但CPU资源都没有用。所以正常占用的时间比CPU时间较长，但CPU时间是在所有CPU声明的时间总和。如果语句中使用多个CPU，并等待其余的几乎是没有的，然后CPU时间大于占用时间以及。
3、编制时间分析：这一步是声明要编译的时间。因为所有的执行计划是在语句运行时，SQL Server必须编译为他。
编译时间这里是不是0，因为编制主要是CPU的操作，总的CPU时间的占用时间相同。如果这里的差异是大的，就要看是否有在SQLServer系统资源瓶颈。
这里是15毫秒，一个是104毫秒。
4、SQLServer执行时间：此声明真的运行时间。自言是第一次运行时，SQL Server需要从内存中读取数据，在语句运行长我 / O等。所以CPU时间和时间差为171毫秒，和1903毫秒。

一般来说，这个语句需要104 + 1903 + 186 = 2193毫秒，其中CPU时间为15 + 171＝186毫秒。语句的主要时间应用于I/O等待。

现在再次声明，但不要清理任何缓存。
复制代码代码如下所示：
设置统计时间
去
选择不同的（{ }，{ UnitPrice } ProductID）从{ } { } salesorderdetail_test dbo。
在{ ProductID } = 777
去
设置统计时间
去

这个时间比上一次快得多：
复制代码代码如下所示：
sql服务器分析和编译时间：
CPU时间= 0毫秒，占用时间= 0毫秒。
sql服务器分析和编译时间：
CPU时间= 0毫秒，占用时间= 0毫秒。
（4行受影响）
SQLServer执行时间：
CPU时间= 156毫秒，占用时间= 169毫秒。
sql服务器分析和编译时间：
CPU时间= 0毫秒，占用时间= 0毫秒。

当执行计划被重用时，SQL分析和编译时CPU时间是0，时间是0。
由于数据已经缓存在内存中，并且不需要从磁盘读取，所以SQL执行时间CPU为156，占用时间非常接近CPU时间，即169。

这节省了运行1903-169 = 1734毫秒的时间，从这里可以看出，缓存又起着至关重要的作用，该语句的性能。
为了不影响其他测试，运行以下语句以关闭set统计时间
复制代码代码如下所示：
设定统计时间
去

设置统计数据
--------------------------------------------------------------------------------
这个开关可以输出语句的物理和逻辑读取的数量，在分析语句的复杂性方面起着重要的作用。
或者以这个查询为例
复制代码代码如下所示：
DBCC dropcleanbuffers
去
设置统计数据
去
选择不同的（{ }，{ UnitPrice } ProductID）从{ } { } salesorderdetail_test dbo。
在{ ProductID } = 777
去

他的归来是：
（4行受影响）
table'salesorderdetail_test。扫描计数5，逻辑读取15064次，物理读0遍，读15064遍，把逻辑读0次，把物理读0次，把0次吧。
每个输出的含义是：
--------------------------------------------------------------------------------
表：表的名称。这里的桌子是salesorderdetail_test

扫描计数：数进行扫描，根据执行计划的形式扫描几次。一般来说，越大的表的数量扫描，不太好的是，唯一的例外是，如果执行计划选择并行操作，多线程的线程会在同一时间读表，每个线程读取它的一部分，但所有的线程数将显示在这里，有几个线程的并发性，而且会有几次扫描。此时数大一点。

逻辑读取：从数据缓存中读取的页数。页面数量越多，查询访问的数据量越大，内存消耗越大，查询就越昂贵。

检查指标是否应调整，扫描次数减少，扫描范围应缩小，这是可能的。
物理读取：从磁盘读取的页数
摘要：对于查询和预读缓存页面
摘要：物理读+ sqlserver为了完成查询语句并从磁盘页阅读。如果不是0，数据没有被缓存在内存中。运行速度势必会受到影响
LOB的逻辑如下：从数据缓存、文本、ntext、图像读取的页数，大值类型（varchar（max）、nvarchar（max）、varbinary（max））
把物理读：文本、数字图像、ntext、大值类型的页面从磁盘读取
工作摘要：在缓存的数字文本，查询ntext形象，高价值型页
然后再运行它，而不是空的缓存。
复制代码代码如下所示：
设置统计数据
去
选择不同的（{ }，{ UnitPrice } ProductID）从{ } { } salesorderdetail_test dbo。
在{ ProductID } = 777
去

结果集返回：
复制代码代码如下所示：
1 table'salesorderdetail_test。扫描计数5，逻辑读取15064次，物理读0遍，读0遍，把逻辑读0次，
2个高球读0遍，前0次发高球。

该逻辑读取相同或15064页，但物理读为0和读取，这意味着数据已在内存中缓存了第二次，不需要再从磁盘读取。节省时间。为了不影响其他测试，请运行以下语句关闭。
复制代码代码如下所示：
设置统计数据
去

设置统计配置文件
--------------------------------------------------------------------------------
这是三个设置中最复杂的一个，他返回语句的执行计划，以及语句在每一步运行时实际返回的数量的统计信息。
通过这个结果，我们不仅可以得到执行计划，理解语句的执行过程，分析报表的调整方向，并判断SQLServer是好还是不好。
选择正确的执行计划。
复制代码代码如下所示：
设置统计配置文件
去
select count（B. { SalesOrderID }）
从{ } { }一salesorderheader_test dbo。
内部联接{ DBO }。{ salesorderdetail_test } B
答：{ } = { SalesOrderID } SalesOrderID B.
其中A { } > 43659 A. SalesOrderID { SalesOrderID }＜53660
去

返回的结果集非常长。这里是重要的字段
--------------------------------------------------------------------------------

注意：这是从下到上的，也就是说，它从底部开始，直到得到结果集为止，所以在（第1行）显示的行字段的值是这个查询返回的结果集。

有多少线显示SQLServer做了多少步，这里有6条线，表明sqlsrver执行6步骤！！
行的每一步返回的实际行数：执行计划
执行的每个步骤有多少次：执行计划已经运行
stmttext的具体内容：实施计划，执行计划是以树的形式显示，每一行是一种操作步骤，并将结果集返回，它们各有自己的成本。
estimaterows：SQLServer返回行的基础上，估计每桌上的统计信息的步数。当我们分析执行计划，我们经常比较两列行和estimaterows。首先我们确定SQLServer的估计是正确的，所以我们可以更新统计信息是否更新。
estimateio：基于EstimateRows记录和统计字段长度SQLServer，估计我 / O成本每一步产生的
estimatecpu：sqlservr预计CPU成本在每一步的基础上产生的EstimateRows记录和统计字段的长度，和复杂的事情要做。
totalsubtreecost：SQLServer公式一些根据estimateio和estimatecpu，计算每一步的执行计划树的成本（成本包括一步其成本和所有他的下步的总和），下面介绍说，成本是一个字段的值
警告：SQLServer运行预警，每走一步，例如，没有统计信息支持的成本预测，例如。
并行的这一步：执行计划使用并行执行计划吗

从上面的结果可以看出，执行计划分为4个步骤，第一步分为并行的两个子步骤。
步A1（第五线）：找到所有值A. { } > 43659 A. SalesOrderID { SalesOrderID }＜53660从表salesorderheader_test } {
因为表在这个字段上有一个聚合索引，所以SQL可以直接使用这个索引的查找。
SQL预测返回10000条记录，实际上是返回10000条记录。预测是准确的。在这一步的成本是0.202（totalsubtreecost）。
A2（第六线）：找到所有值A. { } > 43659 A. SalesOrderID { SalesOrderID }＜53660从表salesorderdetail_test } {
因为桌子有一个非聚集索引在这一领域，SQL可以直接使用寻求该指标看到SQL查询语句的聪明。虽然只定义了A. { } > 43659 A. SalesOrderID { SalesOrderID } < 53660过滤条件对salesorderheader_test } {表，根据语义分析SQL知道条件是真的对salesorderdetail_test } {。所以SQL选择过滤条件先让加入。这可以大大降低成本和
在这一步中，SQL估计返回50561条记录，实际返回50577。成本为0.127，不高。
步骤B（第四行）：将A2的两个步骤的结果集连接起来，因为SQL知道两个结果集很大，所以他选择了直接匹配散列的连接方法。
SQL预测这个加入可以回到50313线和50577线的真正回归。因为SQL对两表} { SalesOrderID统计信息，这里的预测是非常准确的。
这一步的成本等于totalsubtreecost减去他的步骤，0.715-0.202-0.127 = 0.386.because的预测是非常准确的，你可以相信，这里的成本是每个步骤的实际成本。
步骤C（第三）：连接返回一个结果集，这个步骤的计数（*）值比较简单，计数（*）结果是1，所以预测值是正确的。
事实上，这个步骤的成本是根据前一步（b）连接返回的结果集的大小来估计的，我们知道步骤b的估计返回值是非常准确的，所以在这一步中的成本预测将不是一个大问题。
这树的成本是0.745，减去其子节点的成本，和他自己的成本0.745-0.715 = 0.03。这是一个非常小的一步
步骤B（第二行）：将步骤C返回的值转换为int类型，并作为结果返回
这一步是最后一步，而且更简单。转换数据的数据类型的成本几乎可以忽略不计。因此，这棵树的成本等于他的子节点，所有0.745个节点。
也就是说，他自己的成本是0。
在这种方式中，用户可以了解该语句的执行计划，对SQLServer的预测精度，成本的分配
最后，在不同的SQLServer版本，不同机器的成本可能不同，如SQL2005、SQL2008