sql查询性能调试，用SET STATISTICS IO和SET STATISTICS TIME---解释比较详细

        一个查询须要的CPU、IO资源越多，查询运行的速度就越慢，所以，描述查询性能调节任务的另外一种方式是，应该以一种使用更少的CPU、IO资源的方式重写查询命令，若是可以以这样一种方式完成查询，查询的性能就会有所提升。

        若是调节查询性能的目的是让它使用尽量少的服务器资源，而不是查询运行的时间最短，那么就更容易测试你采起的措施是提升了查询的性能仍是下降了查询的性能。尤为是在资源利用不断变化的服务器上更是如此。首先，须要搞清楚在对查询进行调节时，如何测试咱们的服务器的资源使用状况。
        在开始咱们的例子前，先运行下面的这二条命令（不要在正在使用的服务器上执行），这二条命令将清除SQL Server的数据和过程缓冲区，这样可以使咱们在每次执行查询时在同一个起点上，不然，每次执行查询获得的结果就不具备可比性了：
DBCC DROPCLEANBUFFERS和DBCC FREEPROCCACHE
输入并运行下面的Transact-SQL命令：
SET STATISTICS IO ON  
SET STATISTICS TIME ON
一旦上面的准备工做完成后，运行下面的查询：
SELECT * FROM [order details]

显示结果：

SQL Server parse and compile time: （SQL Server解析和编译时间：） CPU time = 10 ms, elapsed time = 61 ms. ……（1） SQL Server parse and compile time: （SQL Server解析和编译时间：） CPU time = 0 ms, elapsed time = 0 ms. ……（2） （所影响的行数为 2155 行） ……（3） Table 'Order Details'. Scan count 1, logical reads 10, physical reads 1, read-ahead reads 9. （表：Order Details，扫描计数1，逻辑读取10 次，物理读取1 次，预读9次） ……（4） SQL Server Execution Times: （SQL Server执行时间：） CPU time = 30 ms, elapsed time = 387 ms. ……（5）

标志（1）表示SQL Server解析“ELECT * FROM [order details]”命令并将解析的结果放到SQL Server的过程缓冲区中供SQL Server使用所须要的CPU运行时间和总的时间。
标志（2）表示SQL Server从过程缓冲区中取出解析结果供执行的时间，大多数状况下这二个值都会是0，由于这个过程执行得至关地快。
标志（5）表示执行此次查询使用了多少CPU运行时间和运行查询使用了多少时间。CPU运行时间是对运行查询所须要的CPU资源的一种相对稳定的测量方法，与CPU的忙闲程度没有关系。可是，每次运行查询时这一数字也会有所不一样，只是变化的范围没有总时间变化大。总时间是对查询执行所须要的时间（不计算阻塞或读数据的时间），因为服务器上的负载是在不断变化的，所以这一数据的变化范围有时会至关地大。（因为CPU占用时间是相对稳定的，所以可使用这一数据做为衡量你的调节措施是提升了查询性能仍是下降了查询的性能的一种方法。）
标志（4）是SET STATISTICS IO的效果

Scan Count：在查询中涉及到的表被访问的次数。在咱们的例子中，其中的表只被访问了1次，因为查询中不包括链接命令，这一信息并非十分有用，但若是查询中包含有一个或多个链接，则这一信息是十分有用的。（一个循环外部的表的Scan Count值为1，但对于一个循环内的表而言，其值为循环的次数。能够想象获得，对于一个循环内的表而言，其ScanCount值越小，它所使用的资源越少，查询的性能也就越高。所以在调节一个带链接的查询的性能时，须要关注Scan Count的值，在进行调节时，注意观察它是增长仍是减小了。）

Logical Reads: 这是SET STATISTICS IO或SET STATISTICS TIME命令提供的最有用的数据。咱们知道，SQL Server在能够对任何数据进行操做前，必须首先把数据读取到其数据缓冲区中。此外，咱们也知道SQL Server什么时候会从数据缓冲区中读取数据，并把数据读取到大小为8K字节的页中。那么LogicalReads的意义是什么呢？Logical Reads是指SQL Server为获得查询中的结果而必须从数据缓冲区读取的页数。在执行查询时，SQL Server不会读取比实际需求多或少的数据，所以，当在相同的数据集上执行同一个查询，获得的LogicalReads的数字老是相同的。（SQL Server执行查询时的Logical Reads值每一次这个数值是不会变化的。所以，在进行查询性能的调节时，这是一个能够用来衡量你的调节措施是否成功的一个很好的标准。若是Logical Reads值降低，就代表查询使用的服务器资源减小，查询的性能有所提升。若是Logical Reads值增长，则表示调节措施下降了查询的性能。在其余条件不变的状况下，一个查询使用的逻辑读越少，其效率就越高，查询的速度就越快。）

Physical Reads：物理读，在执行真正的查询操做前，SQL Server必须从磁盘上向数据缓冲区中读取它所须要的数据。在SQL Server开始执行查询前，它要做的第一件事就是检查它所须要的数据是否在数据缓冲区中，若是在，就从中读取，若是不在，SQLServer必须首先将它须要的数据从磁盘上读到数据缓冲区中。咱们能够想象获得，SQL Server在执行物理读时比执行逻辑读须要更多的服务器资源。所以，在理想状况下，咱们应当尽可能避免物理读操做。下面的这一部分听起来让人容易感到糊涂了。在对查询的性能进行调节时，能够忽略物理读而只专一于逻辑读。你必定会纳闷儿，刚才不是还说物理读比逻辑读须要更多的服务器资源吗？状况确实是这样， SQLServer在执行查询时所须要的物理读次数不可能经过性能调节而减小的。减小物理读的次数是DBA的一项重要工做，但它涉及到整个服务器性能的调节，而不只仅是查询性能的调节。在进行查询性能调节时，咱们不能控制数据缓冲区的大小或服务器的忙碌程度以及完成查询所须要的数据是在数据缓冲区中仍是在磁盘上，惟一咱们可以控制的数据是获得查询结果所须要执行的逻辑读的次数。所以，在查询性能的调节中，咱们能够问心无愧地不理会SET STATISTICS IO命令提供的PhysicalRead的值。（减小物理读次数、加快SQL Server运行速度的一种方式是确保服务器的物理内存足够多。）

Read-Ahead Reads： 与Physical Reads同样，这个值在查询性能调节中也没有什么用。Read-Ahead Reads表示SQL Server在执行预读机制时读取的物理页。为了优化其性能，SQL Server在认为它须要数据以前预先读取一部分数据，根据SQLServer对数据需求预测的准确程度，预读的数据页可能有用，也可能没用。在本例中，Read-Ahead Reads的值为9，Physical Read的值为1，而LogicalReads的值为10，它们之间存在着简单的相加关系。                    那么我在服务器上执行查询时的过程是怎么样的呢？首先，SQL Server会开始检查完成查询所须要的数据是否在数据缓冲区中，它会很快地发现这些数据不在数据缓冲区中，并启动预读机制将它所须要的10个数据页中的前9个读取到数据缓冲区。当SQL Server检查是否所须要的所有数据都已经在数据缓冲区时，会发现已经有9个数据页在数据缓冲区中，还有一个不在，它就会当即再次读取磁盘，将所须要的页读到数据缓冲区。一旦全部的数据都在数据缓冲区后，SQLServer就能够处理查询了。

 

总结：在对查询的性能进行调节时用一些科学的标准来测量你的调节措施是否有效是十分重要的。问题是，SQL Servers的负载是动态变化的，使用查询总的运行时间来衡量你正在调节性能的查询的性能是提升了仍是没有，并非一个合理的方法。 更好的方法是比较多个数据，例如逻辑读的次数或者查询所使用的CPU时间。所以在对查询的性能进行调节时，须要首先使用SET STATISTICS IO和SET STATISTICS TIME命令向你提供一些必要的数据，以便肯定你对查询性能进行调节的措施是否真正地获得了目的。

======================
1.测试前用二条命令清除SQL Server的数据和过程缓冲区，以保证测试条件相同：
DBCC DROPCLEANBUFFERS和DBCC FREEPROCCACHE
2.SET STATISTICS TIME：看cpu时间   
3.SET STATISTICS IO：关注scan count（计数)------查询读取的表数量；logical read( 逻辑读)次数
======================