第十二周 Statistics Introduction to SQL Server Statistics Statistics and Execution Plans，Maintenanc

SQL Server统计介绍

    SQL Server统计信息是一些系统对象,它们包含索引键值中的数据分布信息,有时还包含常规列值中的数据分布信息。可以对支持比较操作的任何数据类型(如>、<、=等)创建统计信息。

让我们检查来自IDX_BOOKS_ISBN索引统计信息。我们在前一章的列表2-15中创建了 Books表。可以使用 DBCC SHOW_STATISTICS ('dbo.Books',IDX_BOOKS_ISBN )命令。结果如图3-1所示。

图3-1  DBCC SHOW STATISTICS输出

    如您所见，DBCC SHOW_STATISTICS命令返回三个结果集。第一个包含关于统计信息的一般元数据信息，例如名称、更新日期、更新统计信息时索引中的行数，等等。第一个结果集中的Steps列表示直方图中的步骤/值的数量(稍后将详细介绍)。查询优化器不使用密度值，仅用于向后兼容。

    第二个结果集称为密度向量,它包含统计数据(索引)中键值组合的密度信息。它是根据 1 / 不同值的个数这一公式计算的,它表示每个键值组合平均有多少行。尽管 IDX_Books_ISBN索引只定义了一个键列SBN,但它还包含一个聚集索引键作为索引行的一部分。我们的表有1,252,500个唯一ISBN值,ISBN列的密度为1.0/1,252,500=7.984032E-07。所有(ISBN, Booked)列的组合也是惟一的并且具有相同的密度。

    最后一个结果集称为直方图。直方图中的每条记录称为直方图步长,包括统计信息(索引)最左边列中的样本键值,以及从上一个值到当前RANGE_HI_KEY值范围内的数据分布信息。让我们更深入地研究直方图列。

 RANGE_HI_KEY列存储键的样本值。这个值是直方图步骤定义的范围的上界键值。例如，record (step) #3使用RANGE_HI_KEY = '104-0100002488'在图3-1的直方图中存储ISBN > '101-0100001796'到ISBN <= '104-0100002488'之间的间隔信息。RANGE_ROWS列估计区间内的行数。在我们的例子中，记录(步骤)#3定义的区间有8191行。EQ_ROWS指示有多少行具有与RANGE_HI_KEY上界值相等的键值。在我们的示例中，只有一行ISBN = '104-0100002488'。DISTINCT_RANGE_ROWS表示键在这个区间内有多少个不同的值。在我们的例子中，键的所有值都是惟一的，所以DISTINCT AVG_RANGE_ROWS表示区间中每个不同键值的平均行数。在本例中，键的所有值都是惟一的，因此AVG_RANGE_ROWS = 1。

让我们将一组重复的ISBN值插入索引，代码如列表3-1所示。

列表3 - 1。将重复的ISBN值插入索引。

;with Prefix(Prefix) 
as ( select Num from (values(104),(104),(104),(104),(104)) Num(Num) ) 
,Postfix(Postfix) 
as 
( 
select 100000001 
union all 
select Postfix + 1 from Postfix where Postfix < 100002500 
) 
insert into dbo.Books(ISBN, Title) 
select 
convert(char(3), Prefix) + '-0' + convert(char(9),Postfix)
  ,'Title for ISBN' + convert(char(3), Prefix) + '-0' + convert(char(9),Postfix) 
from Prefix cross join Postfix 
option (maxrecursion 0);

-- Updating the statistics 
update statistics dbo.Books IDX_Books_ISBN with fullscan;

现在，如果再次运行DBCC SHOW_STATISTICS ('dbo.Books',IDX_BOOKS_ISBN )命令。同样，您将看到如图3-2所示的结果。

图3-2. DBCC SHOW_STATISTICS 输出

前缀为104的ISBN值现在具有重复值，这将影响直方图。同样值得一提的是，第二个结果集中的密度信息也发生了变化。具有重复值的ISBN s的密度高于(ISBN, BookId)列的组合，这仍然是惟一的。

让我们运行 SELECT BookId, Title FROM dbo.Books WHERE ISBN LIKE ‘114%’语句，声明并检查执行计划，如图3 - 3所示。

图3 - 3  查询的执行计划

大多数执行计划操作符都具有两个重要属性。实际行数指示操作符执行期间处理了多少行。预估行数指示在查询优化阶段为该操作符预估的SQL Server行数。在我们的示例中，SQL Server估计有2625行ISBN s以114开头。如果您查看图3-2所示的直方图，您将看到步骤10存储了ISBN间隔的数据分布信息，其中包括您正在选择的值。即使使用线性逼近，也可以估计行数接近SQL Server确定的行数。

关于统计学，有两件非常重要的事情要记住。

1. 直方图只存储最左侧统计信息(索引)列的数据分布信息。统计中有关于键值的多列密度的信息，但仅此而已。直方图中的所有其他信息只与最左边统计列的数据分布有关。

2. SQL Server在直方图中最多保留200个步骤，而不管表的大小以及是否对表进行分区。每个直方图步骤所覆盖的间隔随着表的增长而增加。这导致在大型表的情况下统计数据不太准确。

在组合索引的情况下，当索引中的所有列都用作所有查询中的谓词时，将具有较低密度/较高惟一值百分比的列定义为索引的最左列是有益的。这将允许SQL Server更好地利用统计数据中的数据分布信息。但是，您应该考虑谓词的扫描参数。例如，如果所有查询都在where子句中使用FirstName=@FirstName和LastName=@LastName谓词，那么最好将LastName作为索引中最左边的列。然而，对于像FirstName=@FirstName和LastName<>@LastName这样的谓词，情况就不同了，因为LastName是不可SARGable的。

 

统计数字及执行计划

默认情况下，SQL Server自动创建和更新统计信息。在数据库级有两个选项可以控制这种行为：
1. Auto Create Statistics控制优化器是否自动创建列级统计信息。此选项不影响始终创建的索引级统计信息。默认情况下启用自动创建统计数据库选项。

2. 当启用Auto Update Statistics database选项时，SQL Server每次编译或执行查询时都会检查统计信息是否过期，并在需要时更新它们。默认情况下还启用自动更新统计数据库选项。

■提示  您可以使用STATISTICS_NORECOMPUTE索引选项控制索引级统计信息的自动更新行为。默认情况下，该选项被设置为OFF，这意味着统计信息将自动更新。更改索引级或表级的自动更新行为的另一种方法是使用sp_autostatssystem存储过程。

SQL Server根据影响统计信息列的INSERT、UPDATE、DELETE和MERGE语句执行的更改数量来判断统计信息是否过时。SQL Server计算更改统计列的次数，而不是更改行的数量。例如，如果您将同一行更改100次，它将被视为100次更改，而不是1次更改。

有三种不同的场景，称为统计信息更新阈值，有时也称为统计信息重新编译阈值，其中SQL Server将统计信息标记为过期。

1. 当表为空时，SQL Server将超过向表添加数据时的统计数据。

2. 当表的行数少于500时，SQL Server在统计数据列每更改500次之后就会超过统计数据。

3.在SQL Server 2016之前和数据库兼容性级别< 130的SQL Server 2016中:当一个表有500行或更多行时，每500 +(表中总行数的20%)更改统计列一次，SQL Server就会超过统计。

在数据库兼容性级别为130的SQL Server 2016中:大表上的统计更新阈值变为动态的，并且取决于表的大小。表的行数越多，阈值越低。对于具有数百万甚至数十亿行的大型表，统计信息更新阈值可能只是表中总行数百分比的一小部分。在SQL Server 2008R2 SP1及以上版本中，还可以使用跟踪标记T2371启用此行为。

表3-1总结了不同版本SQL Server的统计更新阈值行为。

表3 - 1 统计数据更新阈值和SQL Server版本

这就引出了一个非常重要的结论。使用静态统计信息更新阈值，触发统计信息更新所需的统计信息列的更改数量与表的大小成正比。表越大，自动更新统计信息的频率越低。例如，对于一个有10亿行的表，您需要对统计信息列执行大约2亿次更改，以使统计信息过期。如果可能，建议使用动态更新阈值。

让我们看看这种行为如何影响我们的系统和执行计划。此时，表dbo. Books有126.5万行。让我们用前缀999向表中添加250,000行，如列表3-5所示。在这个例子中，我使用的SQL Server 2012没有启用T2371。如果在启用动态统计更新阈值的情况下运行它，您可以看到不同的结果。此外，SQL Server 2014中引入的新的基数估计器也可以更改行为。我们将在本章后面讨论它。

列表3-5 添加列到表dbo.Books

;with Postfix(Postfix) 
as 
( 
select 100000001 
union all 
select Postfix + 1 
from Postfix 
where Postfix < 100250000 
) 
insert into dbo.Books(ISBN, Title) 
select 
'999-0' + convert(char(9),Postfix)
 ,'Title for ISBN 999-0' + convert(char(9),Postfix) 
from Postfix 
option (maxrecursion 0);

现在，让我们运行SELECT * FROM dbo.Books WHERE ISBN LIKE '999%'查询选择具有此前缀的所有行。

如果检查查询的执行计划，如图3-7所示，您将看到非聚集索引查找和键查找操作，即使需要从表中选择近20%的行的情况下，这些操作效率很低。

图3 - 7 选择带有999前缀的行的查询的执行计划

您还将注意到，在图3-7中，索引查询操作符的估计行数与实际行数之间存在巨大差异。SQL Server估计，表中只有31.4行带有前缀999，尽管有250,000行具有这样的前缀。结果，产生了一个非常低效的计划。

让我们通过运行DBCC SHOW_STATISTICS ('dbo.Books', IDX_ BOOKS_ISBN)命令来查看IDX_BOOKS_ISBN统计信息。输出如图3-8所示。正如您所看到的，即使我们向表中插入了250,000行，统计数据也没有更新，而且前缀999的直方图中也没有数据。第一个结果集中的行数对应于上次统计信息更新期间表中的行数。它不包括刚刚插入的250000行。

图 3-8. IDX_BOOKS_ISBN统计

现在让我们使用 UPDATE STATISTICS dbo.Books IDX_Books_ISBN WITH FULLSCAN命令更新统计信息。然后再次执行SELECT * FROM dbo.Books WHERE ISBN LIKE '999%'查询。查询的执行计划如图3-9所示。现在估计的行数是正确的，SQL Server最终得到了一个更高效的执行计划，它使用集群索引扫描，I/O读取比以前少17倍。

图3 - 9。在统计信息更新后选择带有999前缀的行的查询的执行计划

如您所见，不正确的基数估计可能导致非常低效的执行计划。过时的统计数据可能是不正确基数估计最常见的原因之一。您可以通过检查执行计划中的估计行数和实际行数来确定其中的一些情况。这两个值之间的巨大差异通常表明统计数据是不正确的。更新统计数据可以解决这个问题，并生成更有效的执行计划。

 

数据维护

如前所述，SQL Server默认情况下自动更新统计信息。对于小表，这种行为通常是可以接受的;但是，对于具有数百万或数十亿行的大型表，您不应该依赖自动统计信息更新，除非您使用数据库兼容性级别为130的SQL Server 2016或启用了跟踪标志T2371。按照20%的统计信息更新阈值触发统计信息更新所需的更改数量将非常高，因此不会经常触发更新。

在这种情况下，建议您手动更新统计信息。在选择最佳统计维护策略时，必须分析表的大小、数据修改模式和系统可用性。例如，如果系统在营业时间之外没有大量负载，则可以决定每晚更新关键表的统计信息。不要忘记统计数据和/或索引维护为SQL Server增加了额外的负载。您必须分析它如何影响同一服务器和/或磁盘阵列上的其他数据库。

在设计统计数据维护策略时要考虑的另一个重要因素是如何修改数据。对于键值不断增加或减少的索引，您需要更频繁地更新统计信息，例如，当索引中最左边的列被定义为identity或被序列对象填充时。如您所见，如果特定的键值位于直方图之外，SQL Server会大大低估行数。在SQL Server 2014到2016年期间，这种行为可能会有所不同，我们将在本章后面看到。

可以使用UPDATE STATISTICS命令更新统计信息。当SQL Server更新统计信息时，它读取数据的样本而不是扫描整个索引。您可以使用FULLSCAN选项来更改这种行为，该选项强制SQL Server读取和分析来自索引的所有数据。正如您可能猜到的那样，该选项提供了最准确的结果，尽管在大型表的情况下，它可能会引入繁重的I/O活动。

■注意 SQL Server在重建索引时更新统计数据。我们将在第6章“索引碎片”中更详细地讨论索引维护。

可以使用sp_updatestats系统存储过程更新数据库中的所有统计信息。建议您使用此存储过程，并在将其升级到新版本的SQL Server之后更新数据库中的所有统计信息。您应该将其与DBCC UPDATEUSAGE存储过程一起运行，该存储过程纠正编目视图中不正确的页和行计数信息。

有一个sys.dm_db_stats_properties DMV，它显示自上次统计信息更新以来对统计信息列所做的修改数量。利用DMV的代码如列表3-9所示。

列表3-9 使用sys.dm_db_stats_properties

select 
s.stats_id as [Stat ID], sc.name + '.' + t.name as [Table], s.name as [Statistics]
 ,p.last_updated, p.rows, p.rows_sampled, p.modification_counter as [ModCount] 
from 
sys.stats s join sys.tables t on 
s.object_id = t.object_id 
join sys.schemas sc on
 t.schema_id = sc.schema_id 
outer apply 
sys.dm_db_stats_properties(t.object_id,s.stats_id) p 
where 
sc.name = 'dbo' and t.name = 'Books';

查询的结果如图3-11所示，表明自上次统计信息更新以来，对统计信息列进行了250,000次修改。您可以构建一个定期检查sys.dm_db_stats_properties DMV的统计数据维护例程。并使用较大的modification_counter值重新构建统计信息。

图3-11  Sys.dm_db_stats_properties输出

另一个与统计相关的数据库选项是自动异步更新统计信息。默认情况下，当SQL Server检测到统计信息过期时，它将暂停查询执行，同步更新统计信息，并在统计信息更新完成后生成一个新的执行计划。通过异步统计信息更新，SQL Server使用基于过时统计信息的旧执行计划执行查询，同时异步地更新后台统计信息。建议您保持同步统计信息更新，除非系统有非常短的查询超时，在这种情况下，同步统计信息更新可以超时查询。

最后，SQL Server不会在创建新索引时自动删除列级统计信息。您应该手动删除冗余的列级统计对象。