SQL 过滤索引：我是否应该始终对可选列的索引进行过滤？答案

【问题标题】：SQL filtered indexes: should I always put a filter on an index for optional columns?SQL 过滤索引：我是否应该始终对可选列的索引进行过滤？
【发布时间】：2012-05-19 21:02:09
【问题描述】：

对于“大”表，是否有任何理由不对可选列的索引进行过滤？

所以对于列 AAA 上的索引（因为人们可以在 AAA 上搜索），
我可以将过滤器设置为 ([AAA] IS NOT NULL)。
这样可以节省存储空间，从而节省资金。

technet 带来的更多优势：

提高了查询性能和计划质量
降低索引维护成本
降低索引存储成本

人们说最好在索引上为大部分为空的列设置过滤器。但是为什么我不对空列的索引进行过滤，比如 1% 呢？如果只有优点，还有什么理由不做？

【问题讨论】：

标签： sql sql-server-2008 indexing filtered-index

【解决方案1】：

这通常是一个好主意，有两个陷阱：

表格设计器有一个错误（仅在 Denali 之前！）。当它重建一个表时，它会删除所有过滤器。
确保优化器可以静态判断您的谓词绝不允许返回空行。通常，这是因为 SQL NULL 语义（似乎是它们帮助而不是阻碍的唯一情况）。示例：select distinct col from T 不会使用索引，因为可能会找到空值。使用这个：select distinct col from T where col is not null。

过滤后的索引没有得到充分利用。它们甚至可以用来使可为空的列唯一。

我的实用建议：尝试几个月，如果有其他无法预料的问题，请自行了解。

如果您喜欢高级 SQL Server 查询技术，还请查看广告索引视图。它们是一组超级过滤索引（至少在 Enterprise 上）。

【讨论】：

【解决方案2】：

所有索引都有优点和缺点：缺点：

它们占用磁盘空间
他们需要维护（平衡索引树需要定期重组，以确保任何查询优化不使用 bum 数据分布），这可能意味着他们需要下线——如果他们很忙，那就是坏消息
如果频繁插入，他们需要时间即时更新

优点：

设计得当，它们可以消除昂贵的表扫描
设计得当，（覆盖索引）它们可以消除任何表格读取。

所以像往常一样，这取决于。

索引过多会显着降低写入性能
索引过多会显着增加空间使用率
不正确的索引会显着降低读取性能

有些人因为真正了解索引而过上了很好的生活：这里有很多好东西http://www.insidesqlserver.com/

因此，这取决于用户返回索引引用的数据的频率与他们更新索引包含的数据的频率。

稀疏列的索引没有什么不同，但是当列（大部分）为空时，过滤索引更有效。一旦备用性降低（例如 50/50），那么当优化器决定返回数据的最佳计划时，数据的分布就会变得非常重要。过滤后的索引不会知道过滤器外数据的分布 - 有点明显，但需要说明。

【讨论】：

我认为您错过了问题的重点。它与一般的索引无关，它与索引上的过滤器有关。它消除了占用磁盘空间等的缺点。
对不起，我试图指出，在一般考虑建立索引时，总体考虑是从同一个地方开始的。数据密度，读取与写入等。结果应该是索引/无索引，如果索引则索引类型。随着时间的推移和数据分布的变化，您还可以使用丢失/未使用的索引存储过程来调整性能。过滤索引比无索引占用更多空间，比非过滤索引占用更少空间。不想挑起战争！
所以现在我的问题是：你说“列大部分是空的，然后过滤的索引更有效”--> 为什么我不对仅包含的列的索引进行过滤空出 5%，甚至像 1%？（它仍然可能是 500000 行，所以它确实节省了存储空间。）
@ErikDekker - 我认为答案的最后一段涵盖了一个原因。与索引一起创建的统计信息使用相同的过滤器，因此您可能会丢失表的一些密度信息，这意味着优化器在某些情况下可能会做出非最佳决策。但是，我想您可以使用 CREATE STATISTICS 语句来获得两全其美...