过滤列是否应该始终在键/包含中?

Jos*_*ell 10 sql-server filtered-index

我正在考虑在我的 Stack Overflow 数据库副本中创建一个过滤索引。像这样的东西,例如:

CREATE UNIQUE NONCLUSTERED INDEX IX_DisplayName_Filtered
    ON dbo.Users (DisplayName)
    WHERE Reputation > 400000;
Run Code Online (Sandbox Code Playgroud)

我应该总是将过滤表达式中的列(Reputation在本例中)添加到键或索引中,还是将它放在过滤表达式中就足够了?

Jos*_*ell 12

是的!

出于各种原因,将过滤列作为索引的一部分总是更好:要么在键中,要么在包含中

以下是通过在索引中包含过滤列来解决的过滤索引查询问题的一些具体示例。

查询谓词与过滤器表达式不匹配时的键查找

首先,文档中有关于包含过滤器表达式列的说明:

  • 如果查询谓词在比较中使用与筛选索引表达式不同的列,则筛选索引表达式中的列应该是筛选索引定义中的键或包含列。

因此,如果您有一个类似 的不等式过滤器表达式Reputation > 400000,但您的查询使用了一个类似的谓词WHERE Reputation > 400000 AND Reputation < 450000;,则可能仍会使用过滤后的索引 - 但需要进行键查找以满足查询的谓词。

Reputation列包含在索引(键或包含)中消除了此查找的需要。

有关其他详细信息和这种情况的示例,请参阅 Erik Darling 的文章过滤索引:只需添加包含

另一个例子可以在 Paul White 的回答中找到:使用过滤索引时执行不必要的键查找

结果集中包含过滤列时的键查找

文档接着说:

  • 如果列在查询结果集中,则过滤索引表达式中的列应该是过滤索引定义中的键或包含列。

这可能感觉不言而喻,但只是为了完整:如果您的查询在最终结果集中包含过滤列,您可能应该将它们包含在索引中(键或包含)。

使用等式表达式时行估计不佳

在优化过程中(特别是当优化器生成的查询计划转换为物理执行计划时),在某些情况下可以消除基于实际统计信息的有用行估计。包括过滤列可以防止这些更准确的估计被丢弃。

更多细节和一个例子,可以在 Paul White 的回答中找到:Incorrect row估计给出了一个过滤的索引

可以在 dba.se 上找到另一个示例:使用过滤索引查询但估计行数错误

IS NULL在过滤表达式中使用时的键查找

使用过滤表达式创建索引IS NULL可能会产生完全不必要的键查找。请参阅此问题以及 SQL Server 反馈站点上的相关错误报告:为什么不使用 IS NULL 值上的过滤索引?

您可能已经猜到了,提出的解决方法是将过滤列添加为过滤索引中的包含列。