3

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

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

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

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

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

4

1 回答 1

1

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

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

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

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

所以来回答你的问题..

第一个问题是，我是否需要将 UserID 显式包含为包含列，或者它是否会由于包含它的集群键而隐含地存在？

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

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

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

第二个问题是，如果不包含冗余，那么明确包含它是否有好处。

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

例如，它是否会确保将来包含 UserID，即使集群键发生更改以排除 UserID 并重建索引？

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

于 2016-08-04T20:12:12.010 回答