sql-server - 在已经是聚簇键一部分的非聚簇索引中包含 "include"列有什么影响？

Question

假设我在 (RetailerID, PurchaseDate, UserID) 上对表进行集群。那就是“聚簇键”，聚簇键总是包含在所有非聚簇索引中。 https://stackoverflow.com/a/23057196/88409 https://stackoverflow.com/a/2747869/88409

接下来，我创建了一个以(RetailerID、StoreID、PurchaseDate)为键的非聚集索引“StorePurchasesIndex”，以便更快地查找仅包含特定商店子集的查找。

第一个问题是，我是否需要将 UserID 显式包含在包含的列中，或者它是否会通过包含它的集群键隐式存在？我很确定在这种情况下我不需要显式包含 UserID，但如果我错了请纠正我。

我真正想知道的是，如果我明确地将 UserID 作为包含列包含会发生什么。它是否会冗余地包含在索引中，一次作为集群键的一部分，然后再次作为包含的列？还是 SQL Server 识别意图并避免存储它两次，因为它已经凭借集群键包含在内？

第二个问题是，如果它不是多余的，那么明确包含它是否有好处。例如，即使集群键以排除 UserID 并重建索引的方式更改，它是否会确保将来包含 UserID？

Answer 1

对于非聚集索引，索引键/键默认存在于根级和叶级。

此默认情况因非聚集索引的定义而异。

当您创建非唯一聚集索引时，SQL Server 将在根目录添加聚集键以使其唯一，并且它也将出现在叶级中。

当您创建唯一聚集索引时，SQL Server 不会在根级别包含聚集键，但会在叶级别包含。

所以来回答你的问题..

The first question is, do I need to explicitly include UserID as an included column, or will it be there implicitly by virtue of the clustering key including it?

是的，你是对的，你不需要在包含列表中添加 userid..

What I'm really interested in knowing is what happens if I do explicitly include UserID as an include column. Will it be included in the index redundantly, once as part of the clustering key, and again as an included column? Or does SQL Server recognize the intent and avoid storing it twice since it's already included by virtue of the clustering key?

SQL Server 足够聪明，可以忽略这一点..

The second question is, if it's not included redundant, then is there a benefit to including it explicitly.

即使添加SQL Server也会忽略该列

For example, will it ensure UserID is included in the future, even if the clustering key changes in such a way that it excludes UserID and the index is rebuilt?

您不能更改聚簇键定义，您必须删除并重新创建它，因此当聚簇键更改时，非聚簇索引会根据其定义重建，因此用户 ID 将存在