过滤索引统计刷新阈值

Question

我们在生产环境中过滤了索引。在对它们进行一些研究时，我看到了这篇文章“过滤的索引和过滤的统计数据可能会严重过时”

这是一个基于代码值 0 的相当简单的过滤索引

CREATE NONCLUSTERED INDEX 
    [IX_InsuranceOffer_FIX_OfferCode0] 
    ON [dbo].[InsuranceOffer]
(
    [OfferId] ASC
)
WHERE ([OfferStatus]=(0))
WITH (PAD_INDEX = OFF,   STATISTICS_NORECOMPUTE = OFF
, SORT_IN_TEMPDB = OFF,  DROP_EXISTING = OFF
, ONLINE = OFF,          ALLOW_ROW_LOCKS = ON
, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]

分布看起来像

code   codeCount   code_distribution
------ ----------- -----------------
6      26186769    93.7526
0      1743401     6.2416
5      1107        0.0040
7      495         0.0018

我们的意图是修改现有索引以包含代码 5。基于这篇引爆点文章，我相信两个查询都应该继续使用过滤索引。

我对试图了解代码易变性的系统所有者有疑问。

在那之前，我查看了sys.dm_db_index_physical_stats试图了解我们当前的索引重建/重组策略是否足以跟上过滤后的索引。我怀疑不是，但我的内功很弱。

index_level avg_fragmentation_in_percent            fragment_count       avg_fragment_size_in_pages page_count           avg_page_space_used_in_percent          record_count
----------- --------------------------------------- -------------------- -------------------------- -------------------- --------------------------------------- --------------------
0           0.6276                                  20                   143.4                      2868                 90.0984                                 1743401
1           42.8571                                 7                    1                          7                    86.0285                                 2868
2           0.0000                                  1                    1                          1                    1.4455                                  7

sys.stats 此索引显示它的最后更新时间为 '2012-01-06 22:03:11.147'

上述数据是否足以作为索引重建决策的基础，或者我是否需要涉及其他指标？或者，对于过滤索引，我们是否甚至关心碎片，而应该只在 X 间隔显式更新统计信息？

我声称答案“视情况而定”

只有半相关的问题是过滤索引的最小行数？

Answer 1

你在这里有两个问题：

上述数据是否足以作为索引重建决策的基础，或者我是否需要涉及其他指标？

一个缺失的环节是索引的大小。如果您谈论的对象少于 1000 页，那么索引重建并不是那么重要。

另一个缺失的环节是索引的流失。通常，当它们是整个表的一个非常非常小的子集时，我会看到使用过滤索引，并且该子集变化很快。通过筛选字段的名称 (OfferStatus = 0) 猜测，听起来您只是在索引尚未提供报价的行，然后您将立即转身并提供报价。在这种情况下，数据变化如此之快以至于索引重建通常没有意义。

或者，对于过滤索引，我们是否甚至关心碎片，而应该只在 X 间隔显式更新统计信息？

当大约 20% 的数据发生变化时，SQL Server 会更新对象的统计信息，但过滤索引和统计信息是一种特殊情况。当 20% 的数据发生变化时，它们也会更新 - 但它是基表的 20%，而不是过滤子集的 20%。因此，您可能希望定期手动更新它们的统计信息。我喜欢Ola Hallengren 的维护脚本- 索引维护存储过程有一个用于更新统计信息的参数，另一个用于选择您想要的采样级别的参数，以及另一个用于选择是更新所有对象的统计信息还是仅更新对象的统计信息的参数改变了行。这是梦幻般的。