包含列与过滤索引

我们目前正在使用名为tb_tranfers的表。该表有4000万行，大小约为26 GB（数据11 GB，索引15 GB）。

10％到15％的行是软删除的行（DeletedDate不为null）。该应用程序仅使用DeletedDate为null的行。对该表的所有查询都将包含一个用于此目的的子句。

该表上有15个索引。缺少索引DMV包含使用DeletedDate作为包含列创建索引的建议。

WHERE DeleteDdate IS NULL在所有11个非簇状索引上使用筛选索引是否有帮助？还是将DeletedDate列作为包含的列会更好？

是的，将所有11个NC索引修改为过滤索引（CREATE INDEX ... ON ... WHERE DeletedDate IS NULL）会有所帮助。这样，您将获得两个优点：

• 查询优化器将知道，任何行从这些指标来已经不会满足于DeletedDate查询过滤器，所以它不会来查找聚集索引仔细检查DeletedDate
• 所有NC索引的大小将减小10-15％，从而需要更少的内存和更少的IO操作进行查找。

需要权衡的是，任何照看软删除的行的查询（必须要有一些查询，否则行为什么存在？）将无法使用这些NC索引。

如果您始终DeletedDate IS NULL在查询中使用过滤器，则可以，通过添加过滤器，您可能会看到性能显着提高。

引擎检查要查找相关行的页面要少得多，这意味着IO更少（速度更快）。

将其添加为INCLUDED字段将毫无用处。由于您始终将其包含在过滤器中（但可能永远不会将其添加到SELECT列表中），因此，如果将其添加为，则永远不会引用该字段INCLUDE。

由于85-90％的行的DeletedDate为NULL，因此仅由DeletedDate组成的索引的选择性对于SQL使用该索引来说是不可能的。但是，与其他更具选择性的列结合使用时，如果将DeletedDate附加到现有索引上，则可以增加索引的整体选择性，从而带来一些好处。

就像JNK所说的那样，除非在SELECT子句中使用DeletedDate，否则它在覆盖索引方面几乎没有用。

鉴于索引的存储量已经大于数据的存储量，您可能还想查看现有的15个NC索引中是否存在任何冗余。