在已包含集群密鑰的非聚集索引中包含“包含”列會產生什么影響？

Question

假設我在（ 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並重建索引的方式更改？

Answer 1

對於非聚簇索引，默認情況下，索引鍵/鍵存在於根級別和葉級別。

此默認情況因非聚集索引的定義而異。

當您創建一個非唯一的聚簇索引時，SQL Server將在root用戶添加聚簇鍵以使其唯一，並且它也將存在於葉級別中。

創建唯一的聚簇索引時，SQL Server不會在根級別包含聚簇鍵，但會包含在葉級別。

所以提出你的問題..

第一個問題是，我是否需要明確地將UserID作為包含列包含在內，還是由於包含它的聚類鍵而隱式存在？

是的，你是對的，你不需要在包含列表中添加用戶ID。

我真正感興趣的是，如果我明確地將UserID作為包含列包含在內，會發生什么。 它是否會作為群集密鑰的一部分冗余地包含在索引中，並再次作為包含列？ 或者SQL Server是否識別意圖並避免將其存儲兩次，因為它已經通過群集密鑰包含在內？

SQL Server很聰明，可以忽略它。

第二個問題是，如果它不包括多余，那么明確包含它是否有好處。

即使您添加SQL Server也會忽略該列

例如，它是否會確保將來包含UserID，即使群集密鑰以排除UserID並重建索引的方式更改？

您無法更改聚簇鍵定義，您必須刪除並重新創建它，因此當聚簇鍵更改時，非聚簇索引將根據其定義重建，因此userid將存在