使用所有列都包含INCLUDE的索引是否正確？

Question

在調試SQL查詢時，SQL Server Dev Studio建議我必須創建如下索引：

CREATE INDEX IX_MY_INDEX ON T_EVENT (F_ORIGINAL_ID, F_EVENT_SEQUENCE_NO) 
     INCLUDE (F_USER_ID,  F_REVISION_NO, ... <about 30-40 columns>)

因此，在INCLUDE建議包含大量的列。

盡管我確實知道在main index子句中使用所有列是一個糟糕的設計，但是在INCLUDE使用所有字段的缺點是什么？ 還是在INCLUDE之后有很多列的索引完全可以（在性能和優化方面）？

Answer 1

缺點是存儲和維護。 每當基礎數據發生更改時，數據將被復制並更新索引。 好處是索引將避免在計划中查找鍵，以便檢索查詢所需的其他列。

請記住，該索引只是建議，而不是建議。 最好將現有的聚集索引更改為非聚集索引（也許通過選擇性地包含列來優化查詢），並使建議的索引成為聚集索引。 是否合適取決於您的工作量和查詢組合。 一個好的索引策略需要一種整體方法，而不是專注於單個查詢/索引。

Answer 2

本質上，這就是聚集索引的作用。 因此，如果表沒有聚簇索引，則可以使用索引的相關列來創建一個。

將所有列都包括在內是個好主意嗎？ 我想說，作為一般慣例 ，這不是一個好主意。 但是肯定有一些特定的情況是有用的。 基本上，索引是表上所有查詢的覆蓋索引。 因此，如果使用索引，則沒有對數據頁的引用。

有缺點：

• 插入，更新和刪除速度較慢。 即使對非索引鍵的更新也會影響索引。
  • 索引“等於”表（實際上有點大，因為索引中有額外的開銷）。
• 較大的索引在維護數據庫方面具有級聯效應，例如更長的備份/恢復和更長的碎片整理。