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

请问有没有办法知道更新表/索引统计数据的适当时间

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

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

一般来说，我们将autostats设置为on，表/索引统计数据在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_键——该指数基于注册日期，在2018年7月最后更新的统计数据之后没有范围。 （该索赔由用户在搜索2018年9月记录时提出）

因此，我决定更新表/索引统计数据，并确认相同的查询从1小时45分钟改进为3.5分钟

Deelpy感谢所有关于我问题的建议

---

致以最良好的祝愿。

您可以自动更新统计信息，这很好。此外，每次重建索引时，都会重新计算统计信息。SQL Server 2008R2以后的版本（直到2016年）与TF 2371具有相同的行为，这意味着大表需要更少的行才能更改为自动计算

此外，还显示了单个索引的统计信息，而不是整个表的统计信息。该索引可以被过滤。并且，请记住为统计计算而采样的总行数。如果采样的行数<行数，则显示的直方图和密度结果将基于采样的行数进行估计

回到性能的核心问题。。。您关注的是统计数据和索引，这不是一个糟糕的想法，但不一定是根本原因。您需要确定哪个查询运行缓慢。然后，按照博客中的步骤，以及其他步骤。这里最大的一个问题是询问关于执行计划的查询。问题可能是索引，也可能是：

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

---

您如何知道您的性能问题是由于统计数据问题造成的？我想说，您需要一个很好的理由来偏离推荐的指导原则：谢谢您的参考，@user1443098。但我认为指数碎片化似乎很低。如果有误解，请让我知道。IIUC，你问什么时候更新统计数据和索引。除特殊情况外，我会根据指南设置autostats并重新生成索引。而且，我已经看到了其中的一些@用户1443098再次感谢：）非常感谢您的善意和明确的建议，@scsimon。正如您所提到的，性能问题可能是由许多因素引起的，不仅仅是简单的统计数据和索引——实际上，内存争用、磁盘速度慢和磁盘可用空间低可能是系统中的其他原因。我将根据“统计直方图和密度向量内部”更深入地检查我们的数据集市表，您亲切地介绍，这非常有趣：）非常感谢。在参考您的文档和一些索引后，缺少“范围\高\键”，哪个键基于注册日期。因此，我决定更新统计数据，并确认性能有了很大提高。非常感谢您提供的所有有用信息：）（我将在我的帖子上更新结果以供参考）完全不用担心@Sachiko