此时，我where后使用ref值作为查询条件，但是给定不同的值，我们可以看出根据统计信息，查询分析器做出了不同的选择，如图2所示

根据公式可以推断，当表中的数据量逐渐增大时，密度会越来越小。

在没有任何统计索引和统计信息的情况下，优化器再一次在流聚合运算符的输出里估计行数是266。我们再次检查下这个表的统计信息。

当然，我们也可以使用如下语句手动更新统计信息。

列级统计信息

但是对于比如

统计信息如何影响查询

1 EXEC SP_HELPSTATS 'SalesOrderDetail_NoStats', 'ALL'

where date = getdate() where id= 12345 where monthly_sales 10000 / 12
where name like Careyson + %

那么，根据这个公式，如果我做查询时，估计的行数就会为如图4所示的数字。

通过下面语句我们可以看出，这表没有任何的统计信息。

简介 SQL
Server查询分析器是基于开销的。通常来讲，查询分析器会根据谓词来确定该如何选择高效的查询路线,比如该选择哪个索引。而每次查询分析器寻找路径时，并不会每一次都去统计索引中包含的行数，值的范围等，而是根据一定条件创建和更新这些信息后保存到数据库中，这也就是所谓的统计信息。

where col1 =1 and col2=2

在执行计划里，在流聚合运算符的输出里，我们看到估计行数是266。在ProductID列唯一值（个数）可以从密度表里拿到。但我们怎么证明查询优化器是用这个值来计算估计行数。我们创建另外一个没有任何索引的SalesOrderDetail表。

图7.通过系统视图查看统计信息

UPDATE STATISTICS 表名[索引名]

• 澳门新葡8455最新网站，Name ：索引名称
• Updated ：统计信息更新时间
• Rows ：索引里行数目。不是表里的行数。
• Rows Sampled
  ：用于生成统计信息的采样行数。创建索引的时候，会进行完全扫描。
• Steps ：直方图里的步长。（第3部分的内容）
• Density ：在SQL
  Server里不再使用，向老版本兼容。
• Average key
  length ：索引键平均长度。
• String
  Index ：用于like时估计统计行数。
• Filter
  Expression ：过滤索引表达式
• Unfiltered Rows
  ：未过滤的行数，如果不存在过滤索引，则等同于Row列。

图2.根据不同的谓词，查询优化器做了不同的选择

当开启了自动更新后，SQL
Server监控表中的数据更改，当达到临界值时则会自动更新数据。这个标准是:

密度向量用来衡量列的唯一性或列的选择性。密度向量的值在0和1之间。如果这列的密度值为1，表示这列的所有记录值一样，选择性低。更高的密度带来更低的选择性。如果这列的密度值为0.003，表示这列有1/0.003=333个不同值。

对于那些不能根据采样步长做出选择的查询，查询分析器使用密度来估计行数,这个公式为:估计的行数=表中的行数*密度

SQL
Server还可以针对不属于任何索引的列创建统计信息来帮助查询分析器获取”估计的行数“.当我们开启数据库级别的选项“自动创建统计信息”如图6所示。

1 DBCC SHOW_STATISTICS('dbo.SalesOrderDetail', 'ix_SalesOrderDetailID')

如何查看统计信息 查看SQL Server的统计信息非常简单，使用如下指令：

对于那些不能根据采样步长做出选择的查询，查询分析器使用密度来估计行数,这个公式为:估计的行数=表中的行数*密度

在密度表里可以看到2行记录，即使我们的非聚集索引是在单列上。这是因为聚集键是非聚集索引的一部分（参见索引深入浅出(4/10)：非聚集索引的B树结构在聚集表）。

图4.估计的行数

图4.估计的行数

输出结果有3个表，分别是：统计信息头，密度向量和直方图。

图6.自动创建统计信息

我们可以通过系统视图sys.stats来查看这些统计信息,如图7所示。

可以使用DBCC
SHOW_STATISTICS加WITH DENSITY_VECTOR来只获取密度向量信息。

文章介绍了关于SQLServer中统计对于查询的影响性能测试，有需要了解sql服务器性能或提升性能的朋友可以仔细的参考一下。

此时，我where后使用ref值作为查询条件，但是给定不同的值，我们可以看出根据统计信息，查询分析器做出了不同的选择，如图2所示。

1 DBCC SHOW_STATISTICS('dbo.SalesOrderDetail_NoStats', '_WA_Sys_00000005_7E6CC920') 

因此，可以看出，估计的行数是和实际的行数有出入的，当数据分布均匀时，或者数据量大时，这个误差将会变的非常小统计信息的更新
由上面的例子可以看到，查询分析器由于依赖于统计信息进行查询，那么过时的统计信息则可能导致低效率的查询。统计信息既可以由SQL
Server来进行管理，也可以手动进行更新，也可以由SQL
Server管理更新时手动更新。

我们来验证一下这个结论,如图5所示。

当这个选项设置为True时，当我们where谓词指定了不在任何索引上的列时，列的统计信息会被创建，但是会有以下两种情况例外:

因此，可以看出，估计的行数是和实际的行数有出入的，当数据分布均匀时，或者数据量大时，这个误差将会变的非常小。

统计信息如何影响查询
下面我们通过一个简单的例子来看统计信息是如何影响查询分析器。我建立一个测试表，有两个INT值的列，其中id为自增，ref上建立非聚集索引，插入100条数据，从1到100，再插入9900条等于100的数据。图1中的统计信息就是示例数据的统计信息。

where date = getdate() where id= 12345 where monthly_sales < 10000 /
12 where name like “Careyson” + “%”

在我们定义索引时，统计信息会自动创建。除此之外，当列在查询里被引用，作为WHERE条件的一部分，在group
by子句里或join条件里，统计信息都会创建。为了自动创建统计信息，在数据库层里的AUTO_CREATE_STATISTICS 设置应该被启用。默认情况下这个设置是被启用的。除此之外，统计信息可以使用CREATE
STATISTICS命令创建。

图1.统计信息

密度的公式是：1/表中唯一值的
个数。当密度越小时，索引越容易被选中。比如图1中的第二个表，我们可以通过如下公式来计算一下密度:

在统计信息头，我们注意到Rows
Sampled 值比Rows值小。这是因为在自动创建统计信息时，SQL
Server没有扫描整个表，只扫描了表的样本。为什么会这样在接下来的文章里会谈到。简而言之，在非聚集索引字段里，统计信息帮助优化器在每一步操作时判断估计行数，什么样的连接是合适的，还有在计划中的执行顺序。