更新 18 TB 数据库的统计信息

根据您的问题，我可以想到四个可能导致您遇到的问题的统计问题。

1. 统计数据没有足够频繁地自动更新。

在 SQL Server 2012 中，仅当表中 20% 或更多的行发生更改后，才会更新统计信息。这意味着对于 10 亿行表，您需要在统计信息更新发生之前修改 2 亿行。随着表变大，您的统计信息更新将变得越来越少，因此 SQL Server 可以多年不更新大型表的统计信息。

TF 2371更改了阈值，以便更频繁地更新统计信息。在 SQL Server 2016 中，此更改已成为我的默认设置。

2. 工作量中的查询容易受到升序关键问题的影响。

考虑一个表，该表每天加载新数据，并且查询过滤最近一天的数据。除非在数据加载后立即更新统计信息，否则新数据不会出现在任何统计直方图中。由于基数估计值低，这可能导致查询性能非常差。

SQL Server 2014 中的新 CE 在这方面进行了改进。如果您要求直方图范围之外的数据，它可能会做出更乐观的猜测，并假设表中有数据但直方图中没有。在 SQL Server 2012 中，您可以通过更频繁地更新统计信息或启用TF 4139来解决此问题（如果有）。TF 4139 仅适用于带有索引的列。SQL Server 可能会对索引运行非常快速的查询以获取最高或最低值，并将临时修改相关统计对象的直方图。这可以为某些查询制定更好的计划。

3. 您的查询等待统计信息更新。

默认情况下，如果查询加载过时的统计信息更新，它将在创建查询计划之前更新该统计信息对象。在 SQL Server 2012 上，抽样统计更新将使用MAXDOP 1. 如果针对大型表启动，则该过程可能会在等待统计信息更新完成时超时。在针对表更新统计信息后，查询性能更好，因为它不再需要等待统计信息更新。

如果您遇到此问题，可以通过使用该NORECOMPUTE选项进行更主动的统计维护来解决此问题。或者，您可以尝试通过升级到 SQL Server 2016 来加快统计更新速度。在 SQL Server 2016 上，抽样统计更新可以并行运行。

另一种选择是打开该AUTO_UPDATE_STATISTICS_ASYNC选项。如果查询计划遇到过时的统计对象，它将将该统计对象排队以由后台作业更新。这听起来可能很糟糕，而且确实如此。查询可能会使用陈旧的统计信息执行。当您没有更好的选择时，您想要打开这种功能，例如在使用自动统计更新太昂贵或对计划形状没有足够帮助的大型系统时。Jack Li 在博客中介绍了一位通过此选项获得帮助的客户。

4. 您的工作负载将受益于手动统计更新，其采样率高于自动采样率。

一些查询和工作负载需要超过默认的统计采样率才能达到可接受的性能。这在大型数据库上可能很难做到，但在 SQL Server 的更高版本中有一些技巧和一些增强功能会有所帮助。

如果您非常了解您的数据和工作量，您可以关闭自动统计更新。您可以收集所需的统计数据FULLSCAN并在适当的时候更新它们。这种方法需要大量的工作和对服务器的大量关注。

如果您有一个重建索引的现有维护过程（其中的智慧有争议）请注意重建索引会自动更新统计信息FULLSCAN，因此如果您构建维护解决方案来更新统计信息，也许您可​​以利用这一点。

请注意，收集抽样统计信息可能不会比全扫描统计信息快，尤其是在对直方图列进行索引的情况下。SQL Server 可以并行进行全扫描统计更新。它也可以在对索引列进行全扫描时避免排序，但在对列进行采样时不会避免排序。事实上，对于足够大的表，如果它们填满 tempdb，则针对未索引列的统计信息更新可能会失败。

SQL Server 2014 引入了增量统计。假设您有一个分区表，并且仅在一个分区中修改了大量数据。以前，要更新表上的统计信息，您必须查看所有分区。有了这个新功能，就可以只收集有关已更改分区的新统计信息。SQL Server 能够将分区中的统计信息汇总到一个表级对象中。

如果您无法升级，您可以考虑将一些表转换为分区视图。视图中的每个表都会有自己的统计对象，因此如果您根据日期加载数据，您可能只需要更新视图中最新表的统计信息，而不是视图的所有表。

最后，如前所述，SQL Server 2016 可以并行更新抽样统计信息：

从 SQL Server 2016 开始，在使用兼容级别 130 时，并行进行数据采样以构建统计信息，以提高统计信息收集的性能。每当表大小超过某个阈值时，查询优化器将使用并行样本统计信息。