SQL Server：如何检测更新表/索引统计信息的适当时机

Question

请问有什么方法可以知道更新表/索引统计的合适时机吗？

最近，我们的 BI-DWH 中的主要数据集市表之一 SQL Server 2012 的性能越来越差。 所有索引每个周末都会根据它们的碎片百分比进行重组/重建，现在它们低于 avg_fragmentation_in_percent 的 5%。

所以我们检测到这是由过时的表/索引统计信息或表碎片等引起的。

一般来说，我们设置了 autostats，并且 Table/index 统计信息在 2018 年 7 月更新，也许现在还不是时候根据他们的优化器进行更新， 由于这张表很大，总记录在7亿左右，每天增加约50万条记录。

这是该表的 PK 统计数据和实际记录数。

-- statistics

dbcc show_statistics("DM1","PK_DM1")

Name    Updated Rows        Rows            Sampled     Steps   Density     AveragekeylengthString      Index   Filter Expression   Unfiltered Rows
------------------------------------------------------------------------------------------------------------------------------------------------------
PK_DM1  07 6 2018  2:54PM   661696443       1137887     101         0                       28          NO          NULL                661696443

-- actual row count

select count(*) row_cnt from DM1;

row_cnt
-------------
706723646

-- Current Index Fragmmentations

SELECT a.index_id, name, avg_fragmentation_in_percent  
FROM sys.dm_db_index_physical_stats (DB_ID(N'DM1'), 
      OBJECT_ID(N'dbo.DM1'), NULL, NULL, NULL) AS a  
    JOIN sys.indexes AS b 
      ON a.object_id = b.object_id AND a.index_id = b.index_id;   
GO  

index_id    name    avg_fragmentation_in_percent
--------------------------------------------------
1        PK_DM1             1.32592173128252
7        IDX_DM1_01         1.06209021193359
9        IDX_DM1_02         0.450888386865285
10       IDX_DM1_03         4.78448190118396

因此，统计行数和实际记录数之间的差异不到 10%，但超过 4500 万。 我想知道在这种情况下是否值得手动更新表/索引统计信息。

如果您有任何其他信息决定了更新统计数据的适当时机，我们将不胜感激。

谢谢。

-- 结果

感谢 @scsimon 的建议，我详细检查了所有索引统计信息，发现主索引缺少 RANGE_HI_KEY - 该索引基于注册日期，并且在 2018 年 7 月上次更新统计信息之后没有范围。 （该声明是用户在搜索2018年9月记录时提出的）

所以我决定更新表/索引统计信息并确认相同的查询从 1 小时 45 分钟缩短到 3.5 分钟。

Deelpy 对我的问题的所有建议表示感谢。

最好的问候。

Answer 1

好吧，您可以启用自动更新统计信息，这很好。此外，每次重建索引时，都会重新计算统计信息。从 SQL Server 2008R2 开始，直到 2016 年，其行为与 TF 2371 相同，这意味着大表需要更改为自动计算所需的行数更少。 Read more here on that.

您还显示单个索引而不是整个表的统计信息。该索引可以被过滤。并且，请记住 为统计计算采样的总行数。如果 Rows Sampled You can read more on that here

回到性能的核心问题...您关注的是统计数据和索引，这不是一个糟糕的主意，但不一定是根本原因。您需要确定 what 查询运行缓慢。然后，get help with that slow query，但遵循该博客和其他人中的步骤。这里最重要的是用执行计划询问有关该查询的问题。问题可能是索引，也可能是：

• 内存争用/错误分配
• CPU 瓶颈
• 并行度（也许您将 MAXDOP 设置为 0）
• 慢磁盘
• 内存不足，导致物理读取
• 执行计划不再是最优的，您可能需要重新编译该查询
• 等等等等等等……这就是执行计划和等待统计数据的亮点