在主鍵上包含包含列的第二個索引有什麼好處？
我正在查看我們的數據庫並註意到在特定表上我們有以下索引：
表：
Col1 INT IDENTITY(1,1) Primary Key Col2 INT ... about 15 more columns .... ColN VARCHAR(50) .... another 10 more columns除了 上的標準主鍵聚集索引
Col1，我們還有以下索引：create nonclustered index [iTable-Col1] ON [dbo].[Table1] ( Col1 ) include ( ColN )我們定期搜尋
Col1並且只想檢索ColN. 該索引確實被使用，因為它是包含滿足查詢所需的所有數據的最小索引。我的問題是，這個索引對 SQL Server 有什麼好處嗎？我們是否會更好地放棄它並只在聚集索引上進行搜尋？
我唯一的想法是這個索引比聚集索引（25mb vs 300mb）小得多，這可能會使搜尋和/或記憶體更快。
如果這有什麼不同的話，伺服器是 SQL Server 2012。
大多數時候，這種類型的索引只對那些列的索引掃描有用。
葉級別之上的索引樹結構在樹級別方面通常非常相似，因此如果是這種情況，則導航樹以進行查找操作（不掃描）的性能差異很小或沒有差異。如果你想學習索引內部的基礎知識，我有一個影片可以幫助你。
無論如何，回到掃描。該索引有用的原因與其說是索引本身有關，不如說是關於為什麼不掃描聚集索引（或將這些數據頁保存在記憶體中）。如果其他列使表相對較寬（根據您提供的大小，我會說它們確實如此，儘管不清楚該表在整個數據庫的上下文中有多大），窄索引在某些情況下可能是有益的. 頻繁的掃描（或在許多不同的鍵值上查找）傾向於將整個索引保留在記憶體中，因此索引越大，用於其他對象的記憶體空間就越少，當然這會產生更多的 I/O，如果緩衝池很冷。
雖然這是一個罕見的案例（我記得做過一次或兩次），但這種索引的最大好處是它將極大地幫助想要使用合併連接來連接該表的查詢。（注意：如果索引掃描不合適，請先優化查詢！）在查詢計劃中，對聚集索引的掃描，或在合併連接之前對非聚集索引的掃描和排序可以給出何時可能出現這種情況的指示是個好主意。但同樣，這種情況很少見。查詢應該足夠頻繁地執行，或者基表足夠昂貴以保持卡在記憶體中（即，您不需要一直在那裡），以證明索引的額外儲存和維護是合理的。
如果您不確定現在如何使用此索引，請檢查 DMV
sys.dm_db_index_usage_stats。請記住，在伺服器重新啟動時會重置計數，因此如果您正在考慮刪除索引，請確保它在整個業務週期中都沒有用。