SQL Server 性能：非聚集索引 + INCLUDE 列与聚集索引 - 等效？答案

【问题标题】：SQL Server Performance: Non-clustered Index + INCLUDE columns vs. Clustered Index - equivalent?SQL Server 性能：非聚集索引 + INCLUDE 列与聚集索引 - 等效？
【发布时间】：2011-03-24 00:08:42
【问题描述】：

您好 SQL Server 引擎专家；请与我们分享您的一些见解...

据我了解，非聚集索引上的 INCLUDE 列允许将额外的非键数据与索引页一起存储。

我很清楚聚簇索引相对于非聚簇索引的性能优势，这仅仅是因为引擎在检索中必须采取的步骤减少了 1 步才能到达磁盘上的数据。

但是，由于 INCLUDE 列存在于非聚集索引中，是否可以预期以下查询在方案 1 和方案 2 中具有基本相同的性能，因为在方案 2 中可以从索引页中检索所有列，而不是求助于到表格数据页？

查询

SELECT A, B, C FROM TBL ORDER BY A

场景 1

CREATE CLUSTERED INDEX IX1 ON TBL (A, B, C);

场景 2

CREATED NONCLUSTERED INDEX IX1 ON TBL (A) INCLUDE (B, C);

【问题讨论】：

当您在索引设置之间切换时，实际的查询计划说明了什么？
这将取决于访问该表的整体查询工作负载。
有趣的是，非聚集索引在查询计划中是首选，但使用查询提示的可能性，引擎在根据数据量决定最佳查询计划的复杂性以及谁知道还有什么其他因素离开这对我来说是一个挥之不去的谜。我真的在找人说出来，说 INCLUDE 列并不是他们因为某种原因而被破解的全部......
INCLUDE 列有自己的位置，我认为您的示例对他们来说是一个很好的示例
实际上，附加的 INCLUDEd 列并没有存储在索引页上（假设：所有这些列），而只是存储在 LEAF 级索引页上。因此，如果您有一个包含四级条目的索引，则仅在级别没有。 3 - 叶级 - 你会有额外的列 - 它们不会弄乱整个索引

标签： sql-server optimization indexing query-optimization

【解决方案1】：

对于本示例，您实际上可以使用非聚集索引获得更好的性能。但是，这实际上取决于您未提供的其他信息。以下是一些想法。

SQL Server 将信息存储在 8KB 页面中；这包括数据和索引。如果您的表仅包含 A、B 和 C 列，那么数据将存储在大约相同数量的数据页和非聚集索引页中。但是，如果表中有更多列，则数据将需要更多页。索引页的数量不会有任何不同。

因此，在列数超过查询所需的表中，查询将更好地使用非聚集覆盖索引（包含所有列的索引）。它将能够处理更少的页面以返回您想要的结果。

当然，在获得大量行之前可能看不到性能差异。

【讨论】：

【解决方案2】：

确实，具有覆盖包含列的非聚集索引可以起到与聚集索引完全相同的作用。成本是在更新时：更多的包含列意味着当基表（在聚集索引中）中包含的列值发生更改时，必须更新更多的索引。此外，包含的列越多，数据大小也会增加：数据库变得更大，这会使维护操作变得复杂。

最后，您必须在附加索引的覆盖值和更多包含的列与更新成本和数据大小增加之间找到平衡。

【讨论】：