SQL Server调优系列进阶篇（查询语句运行几个指标值监测）

前言

上一篇我们分析了查询优化器的工作方式，其中包括：查询优化器的详细运行步骤、筛选条件分析、索引项优化等信息。
本篇我们分析在我们运行的过程中几个关键指标值的检测。
通过这些指标值来分析语句的运行问题，并且分析其优化方式。
通过本篇我们可以学习到调优中经常利用的几个利器！
废话少说，开始本篇的正题。


技术准备

数据库版本为SQL Server2008R2，利用微软的一个更简洁的案例库（Northwind）进行分析。
利器一、IO统计
通过这个IO统计能为我们分析出当前查询语句所要扫描的数据页的数量。这里面有几个重要的概念，我们依次分析。
方法很简单，一行代码搞定：

[code= sql; gutter: true">SET STATISTICS IO ON

来看个例子

SET STATISTICS IO ON
GO
SELECT * FROM Person.Contact




这里可以看到这个语句对于数据表的操作次数，基于数据页的扫描项。
所谓的数据页就是数据库的底层数据存储方式，SQL Server以数据页的形式存储表行数据。每个数据页为8K，
8K=8192字节-96字节（页头）-36字节（行偏移）=8060字节
也就说一个数据页存储的纯数据内容为8060字节。
我们依次来解释上面出现几个读取的概念：
逻辑读
表示处理查询所需要访问页的总数。也就是说要完成一个查询语句需要读取的数据页的总数。
这里的数据页有可能来自内存，也有可能来自硬盘读取。
物理读
这个就是说来自硬盘读取的数据页数。我们知道SQL Server每次都会将读取的数据页尽可能存在于内存中，以方便下一次直接读取，提升读取速度。
所以在这里关于存储于内存中的数据页下次访问的概率，提出了一个指标：缓存命中率
EXEC sp_spaceused NewOrders,TRUE
GO




我们可以看到这张表数据页的总大小为2216KB，我们知道一页为8KB，可以推断出这个表的数据页有：
--先清空缓存数据，生产机慎用
DBCC DROPCLEANBUFFERS

SET STATISTICS IO ON

SELECT * FROM NewOrders




我去…
这里的逻辑读取为1047页，和我们上面的推断277页不相符…擦…神马原因！！！
这里就是我们要分析的数据页Forwarded record现象造成的。因为我们在新建立的表，在后面新添加的一列数据：Full_Details，类型为CHAR(CREATE CLUSTERED INDEX orderID_C ON NewOrders(OrderID)
GO
DROP INDEX NewOrders.orderID_C
GO
SET STATISTICS IO ON
SELECT * FROM NewOrders
GO




通过IO统计项，除了可以分析出上面的Forwarded Record页造成的碎片外，更重要的地方使用来对比不同查询语句之间的读取次数，通过降低读取的次数来优化语句。
关于预读的情况，我们在前面已经分析了，其数据时通过另外一个线程在T-SQL查询语句优化的时候进行数据的预加载。
所以这个线程在预读数据的时候其实是有一个参考值的，根据这个参考值读取出来的数据才能保证大部分数据是有用的，也就是提高上面提到的缓存命中率。
关于这个参考值，我分析了下，其实是分为两中情况分析的。
首先、如果是数据表为堆表，SQL Server获取的方式只能通过全表扫描了。而此方式为了避免重复读取，增加消耗，所以一次的预读并非读取一个数据页，
而是一段物理上的连续64个页