包含许多包含列的SQL Server宽索引

Question

我应该小心在非集群索引中添加太多包含列吗？

我知道这会阻止对完全覆盖的查询进行书签查找，但我假设计数器是在列不是静态的情况下维护索引的额外成本以及索引的额外整体大小导致额外的物理读取。

Answer 1

你在问题​​中说过：索引中包含许多索引和/或许多列的风险是，在接收大量CUD（创建/更新/删除）操作的数据库中维护索引的成本可能会变得很大

选择正确的索引是一种排序的艺术，它涉及平衡最常见的用例，以及存储问题（通常是低优先级问题，但在某些情况下很重要），以及CUD操作的性能问题。

Answer 2

我同意mjv - 对此没有真正简单快速的答案 - 这是一种平衡行为。

一般而言，较少但较宽的指数优于许多较窄的指数，而覆盖指数（包括字段）优于不必进行书签查找 - 但这只是概括，而且通常说错了:-)

你真的不能做更多的测试和测量：

• 衡量您感兴趣的领域的表现
• 然后添加您的广泛和覆盖索引
• 再次测量，看看你是否a）获得某些操作的加速，b）剩余的性能不会受到太大影响

所有的猜测和试图找出真的没有帮助 - 测量，做，再次测量，比较结果。这就是你所能做的一切。

Answer 3

我同意这两个答案到目前为止，只想添加两件事：

为了覆盖索引，SQL Server 2005引入了INCLUDE clause，使存储和使用更加高效。对于早期版本，包含的列是树的一部分，是900字节宽度的一部分，并使索引更大。

使用sp_spaceused时，索引的典型值也大于表。数据库主要是读取（我在某处看到“85％读取”），即使写入很重（例如INSERT查找重复项，DELETE检查FK，使用WHERE更新等）。