SQL Server性能：非聚簇索引+ INCLUDE列與聚簇索引 - 等效嗎？

據我所知，非聚集索引上的INCLUDE列允許將其他非關鍵數據與索引頁面一起存儲。

我很清楚聚簇索引對非聚簇索引的性能好處，這是因爲引擎在檢索時必須採取的步驟少一步才能到達磁盤上的數據。

但是，由於INCLUDE列存在於非聚集索引中，因此可以預期以下查詢在場景1和2中具有基本相同的性能，因爲可以從場景2中的索引頁中檢索所有列，而不是訴諸表格數據頁面？

QUERY

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);

2010-08-02 Tahbaza

實際查詢計劃在切換索引設置時會說什麼？ – 2010-08-02 01:40:11

它將取決於查詢該表的總體查詢工作量。 – 2010-08-02 01:52:09

有趣的是，在查詢計劃中首選非聚集索引，但使用查詢提示的可能性，引擎根據數據量決定最佳查詢計劃的複雜性以及誰知道其他因素對我而言是一個謎。我真的很想找人說出來，並說INCLUDE專欄不是因爲某些原因或者其他原因而被破解的...... – Tahbaza 2010-08-02 01:54:30

對於這個例子你可能實際使用非聚集索引可以獲得更好的性能。但是，這實際上取決於你沒有提供的附加信息。這裏有一些想法。

SQL Server將信息存儲在8KB頁面中;這包括數據和索引。如果您的表只包含列A，B和C，則數據將存儲在大致相同數量的數據頁面和非聚集索引頁面中。但是，如果表中有更多列，那麼數據將需要更多頁面。索引頁面的數量不會有任何不同。

因此，在一個表中列的數量多於查詢需求的情況下，查詢對於非聚集覆蓋索引（包含所有列的索引）將會更好地工作。它將能夠處理更少的頁面以返回您想要的結果。

當然，性能差異可能不會被看到，直到你得到大量的行。

2010-08-02 01:59:52 bobs

確實，覆蓋包含列的非聚集索引可以起到與聚集索引完全相同的作用。成本在更新時間：更多包含列意味着在基表（聚集索引中）中包含的列值發生更改時，必須更新更多索引。此外，隨着列數越來越多，數據規模越來越大：數據庫變得越來越大，這可能會使維護操作複雜化。

最後，您必須在附加索引的覆蓋值和更多包含列與更新成本和數據大小增加之間找到平衡點。

2010-08-02 02:04:25

回答