MSSQL之统计信息介绍

简介

SQL Server优化器基于开销（Cost）评估执行计划，选择开销最小的作为“最优化”的执行计划。计算开销的根据是索引及其统计信息，因此，索引和统计数据是非常重要的。查询优化器（Query Optimizer）使用统计信息对查询的开销进行评估（Estimate），选择开销最小的查询计划，作为最终的、“最优的”的执行计划。SQL Server自动为索引列或查询的数据列创建统计信息，统计信息包括三部分：头部（Header），密度向量（Density Vector） 和 分布直方图（Distribution Histogram）。

统计信息是数据分布的反馈，SQL Server根据数据更新的数量和特定的规则自动更新统计信息，一般情况下，表的数据量越大，SQL Server更新统计信息需要的数据更新量越大，随着数据的更新，有些表的数据不会及时更新，以至于统计信息过时，不能真实反映数据的分布情况，用户可以通过命令手动更新统计信息，但是更新统计信息需要扫描数据表，这可能是一个非常耗时的IO密集型操作，用户需要权衡性能的提升和资源的消耗。

SQL Server查询优化器对于执行计划成本的评估是基于数据库统计信息的。所以，数据库统计信息直接影响到数据库查询效率，是数据库系统快速响应，低延迟特性的幕后英雄，但是我们又经常忽视数据库统计信息的存在和维护，怀着为英雄正名和唤醒大家对幕后英雄尊重的目的写作这篇文章。

什么是统计信息

SQL Server查询优化器使用统计信息来评估表或索引视图的一个或多个列中值的分布，这个分布信息提供了用于创建高质量的执行计划的基础（称为基数）。更为通俗一点说，SQL Server的执行计划是基于统计信息来评估的，优化器最终会选择最优的执行计划来为数据库系统提供数据存取功能。这位躲在幕后的英雄便是统计信息。

sql server在快速查询值时只有索引还不够，还需要知道操作要处理的数据量有多少，从而估算出复杂度，选择一个代价小的执行计划，这样sql server就知道了数据的分布情况。索引的统计值信息，还内置策略用来在没有索引的属性列上创建统计值。在有索引和没有索引的属性列上统计值信息会被自动维护。大部分场景下不需要手动去维护统计信息。 　　
作用是 sqlserver 查询优化器使用统计信息来创建可提高查询性能的查询计划。 对于大多数查询，查询优化器已为高质量查询计划生成必要的统计信息。每个索引都会自动建立统计信息, 统计信息的准确性直接影响指令的速度，执行计划的选择是依据统计信息。

Sqlserver 查询是基于开销查询的，在首次生成执行计划时，是基于多阶段的分析优化才确定出较好的执行计划。而这些开销的基数估计，是根据统计信息来确定的。统计信息其实就是对表的各个字段的总体数据进行分段分布，数据库默认都会自动维护。

表和视图都有统计信息，统计信息对象是根据索引或表列的列表创建的。当某列第一次最为条件查询时，将创建单列的统计信息。当创建索引时，将创建同名的统计信息。索引中，统计信息只统计首列，因此索引除了按首列排序存储数据外，其统计信息也是按首列计算统计的，所以索引设置时定义的第一列非常重要。每个统计信息对象都在包含一个或多个表列的列表上创建，并且包括显示值在第一列中的分布的直方图。

统计信息的作用

在关系型数据库系统（RDBMS）中，统计信息非常重要，当然MSSQL Server也不例外，它的准确与否直接影响到执行计划的优劣，数据库系统查询效率是否高效。具体表现在以下几个方面：

• 查询优化器需要借助统计信息来判断是否使用索引。
• 查询优化器需要根据统计信息来判断是使用嵌套循环连接，合并连接还是哈希连接。
• 查询优化器根据表统计信息来找出最佳的执行顺序。

SQLServer中，在执行一个批处理语句时，关系引擎中的查询优化器会先估计生成较优的执行计划，执行执行器才安照此执行计划请求数据。即在生成执行计划期间，sqlserver是根据表中的统计信息进行行数估计，按照脚本语义来确定物理操作步骤生成执行计划，再按照该执行计划访问数据。而对于数据较大的表，按照统计信息估计的行数也常常不准确，这就是使查询使用了不准确的执行计划而比较慢。类似如：“参数嗅探”因传递参数值无法确定而估算错误；使用表变量不会有统计信息也不会估算行数。

如果查询日期范围在'2005-07-01'<ModifiedDate<='2005-08-01' ,看上图，查询返回的估计行数应该为896.7728(190.2021+706.5707)

估计行数为896.773，与统计信息的直方图的信息一致。其实就是根据直方图统计出来的，如果估计行数不准确，一定是统计信息没有正确的直方图信息，因此需要更新统计信息。

在看带参数的测试：

估计行数是495，是直方图里显示ProductID=800的估计。现在使用参数替换。

看到估计行数是456.079，这个估计与实际的相差不大，不影响执行计划改变。但是为什么又变了呢？这个怎么来的？下面解释

ProductID=800的估计行数是495，而使用参数的是456.079，统计信息中并没有记录，但是SqlServer却能根据密度计算。看红框中的数值，因为我是以ProductID为谓词，因此选择了密度 All density = 0.003759399，估计行数为：

有时候即使更新了统计信息，结果还是一样，因为数据量太大，估计数据不完全，看Rows Sampled可知道，因此也可以在更新统计信息时采用全表行数统计，但是这样扫描表数据也耗性能。即便如此，还是有些可能不一样，因为直方图的步长最多200，数据列中相同的和不同的差距太大，200段分布也有参差不齐的数据，不能使用更多步更详细的数据直方图。

统计信息的查看

统计信息不是实时更新的，如果统计信息过期，查询优化器（Query optimizer）可能不能生成高质量的查询计划，必须有必要的调度程序，自动更新统计数据。数据库管理员（DBA）可以使用DBCC SHOW_STATISTICS 能够查看表或索引视图（Indexed view）的统计信息，以及最后一次更新统计信息的日期，如果统计信息过期，可以使用UPDATE STATISTICS命令手动更新统计信息，以使查询优化器依据正确的统计信息生成高效的查询计划。但是，并不是统计信息更新的越频繁越好，更新统计信息是IO密集型的操作，还会导致现有的查询计划的重新编译，建议不要太频繁地更新统计信息，在改进查询计划和查询计划的重新编译之间权衡开销，找到一个平衡点。

target 参数是：索引的名称，统计对象的名称，或者列名。如果target是索引名称，或统计对象的名称，那么该命令返回关于target的统计信息。如果target是数据列，那么该命令会自动在该列上创建统计，返回关于该列的统计信息。

可以看到，统计信息也是表的一种对象。

后续精彩内容已被小麦苗无情隐藏，请输入验证码解锁本站所有文章！

验证码：

请先关注本站微信公众号，然后回复“小麦苗博客”，获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。