SQL Server调优系列进阶篇（深入剖析统计信息）

前言

经过前几篇的分析，其实大体已经初窥到SQL Server统计信息的重要性了，所以本篇就要祭出这个神器了。

该篇内容会很长，坐好板凳，瓜子零食之类...

不废话，进正题

技术准备

数据库版本为SQL Server2008R2，利用微软的以前的案例库（Northwind）进行分析，部分内容也会应用微软的另一个案例库AdventureWorks

相信了解SQL Server的朋友，对这两个库都不会太陌生。

概念理解

关于SQL Server中的统计信息，在联机丛书中是这样解释的

查询优化的统计信息是一些对象，这些对象包含与值在表或索引视图的一列或多列中的分布有关的统计信息。查询优化器使用这些统计信息来估计查询结果中的基数或行数。通过这些基数估计，查询优化器可以创建高质量的查询计划。例如，查询优化器可以使用基数估计选择索引查找运算符而不是耗费更多资源的索引扫描运算符，从而提高查询性能。

其实关于统计信息的作用通俗点将就是：SQL Server通过统计信息理解库中每张表的数据内容项分布，知道里面数据“长得啥德行，做到心中有数”，这样每次查询语句的时候就可以根据表中的数据分布，基本能定位到要查找数据的内容位置。

比如，我记得我以前有篇文章写过一个相同的查询语句，但是产生了完全不同的查询计划，这里回顾下，基本如下：

SELECT * FROM Person.Contact
WHERE FirstName LIKE 'K%'

SELECT * FROM Person.Contact
WHERE FirstName LIKE 'Y%

完全相同的查询语句，只是查询条件不同，一个查找以K开头的顾客，一个查找以Y开头的顾客，却产生了完全不同的查询计划。

其实，这里的原因就是统计信息在作祟。

我们知道，在这张表的FirstName字段存在一个非聚集索引，目标就是为了提升如上面的查询语句的性能。

但是这张表里面FirstName字段中的数据内容以K开头的顾客存在1255行，也就是如果利用非聚集索引查找的方式，需要产生1225次IO操作，这可能不是糟的，糟的还在后面，因为我们获取的数据字段并不全部在FirstName字段中，而需要额外的书签查找来获取，而这个书签查找会产生的大量的随机IO操作。记住：这里是随机IO。关于这里的查找方式在我们篇文章中就有介绍。

所以相比利用非聚集索引所带来的消耗相比，全部的所以索引扫描来的更划算，因为它依次扫描就可以获取想要的数据。

而以Y开头的就只有37行，37行数据完全通过非聚集索引获取，再加一部分的书签查找很显然是一个很划算的方式。因为它数据量少，产生的随机IO量相对也会少。

所以，这里的问题来了：

SQL Server是如何知道这张表里FirstName字段中以K开头的顾客会比较多，而以Y开头反而少呢？。

这里就是统计信息在作祟了，它不但知道FirstName字段中各行数据的内容“长啥样”，并且还是知道每行数据的分布情况。

其实，这就好比在图书库中，每个书架就是一张表，而每本书就是一行数据，索引就好像图书馆书籍列表，比如按类区分，而统计信息就好像是每类书籍的多少以及存放书架位置。所以你借一本书的时候，需要借助索引来查看，然后利用统计信息指导位置，这样才能获取书本。

希望这样解释，看官已经明白了统计信息的作用了。

这里多谈点，有很多童鞋没有深入了解索引和统计信息的作用前提下，在看过很多调优的文章之后，只深谙了一句话：调优嘛，创建索引就行了。

我不否认创建索引这种方式调优方式的作用性，但是很多时候关于建索引的技巧却不了解。更巧的是大部分情况下属于误打误撞创建完索引后，性能果真提升了，而有时候创建的索引却毫无用处，只会影响表的其它操作的性能（尤其是Insert），更有甚者会产生死锁情况。

而且，关于索引项的作用，其实很多的情况下，并不想你想象的那么美好，后续文章我们会分析那些索引失效的原因。

所以遇到问题，其实还要通过表象理解其本质，这样才能做到真正的有的放矢，有把握的解决问题。

解析统计信息

我们来详细分析一下统计信息中的内容项，我们知道在上面的语句中，在表Customers中ContactName列中存在一个非聚集索引项，所以在该列存在统计信息，我们可以通过如下脚本查看该表的统计信息列表

sp_helpstats Customers

然后通过以下命令来查看该统计信息的详细内容，代码如下