我應該使用許多單欄位索引，而不是特定的多列索引嗎？

這個問題是關於 SQL Server 索引技術的有效性。我認為它被稱為“索引交集”。

我正在使用存在許多性能和穩定性問題的現有 SQL Server (2008) 應用程序。開發人員在索引方面做了一些奇怪的事情。我無法獲得關於這些問題的決定性基準，也無法在網際網路上找到任何真正好的文件。

一個表上有許多可搜尋的列。開發人員在每個可搜尋列上創建了一個單列索引。理論上，SQL Server 將能夠組合（相交）這些索引中的每一個，以在大多數情況下有效地訪問表。這是一個簡化的範例（真實表有更多欄位）：

CREATE TABLE [dbo].[FatTable](
   [id] [bigint] IDENTITY(1,1) NOT NULL,
   [col1] [nchar](12) NOT NULL,
   [col2] [int] NOT NULL,
   [col3] [varchar](2000) NOT NULL, ...

CREATE NONCLUSTERED INDEX [IndexCol1] ON [dbo].[FatTable]  ( [col1] ASC )
CREATE NONCLUSTERED INDEX [IndexCol2] ON [dbo].[FatTable] ( [col2] ASC )

select * from fattable where col1 = '2004IN' 
select * from fattable where col1 = '2004IN' and col2 = 4

我認為針對搜尋條件的多列索引要好得多，但我可能錯了。我已經看到查詢計劃顯示 SQL Server 在兩個索引搜尋上進行雜湊匹配。當您不知道如何搜尋表格時，這可能有意義嗎？謝謝。

您需要的是覆蓋索引，即。可以自行滿足查詢的索引。但是“覆蓋”索引有一個問題：它覆蓋了一個特定的查詢。因此，為了開發一個好的索引策略，您需要了解您的工作量：哪些查詢正在訪問數據庫，哪些是關鍵的，哪些不是，每種類型的查詢的執行頻率等等等等。然後你將此與每個索引的寫入和更新成本進行平衡，您就有了索引策略。如果這聽起來很複雜，那是因為它很複雜。

但是，您可以應用一些經驗法則。MSDN 很好地涵蓋了基礎知識：

• 索引設計基礎
• 通用索引設計指南
• 聚集索引設計指南
• 非聚集索引設計指南

社區還貢獻了無數的文章，例如。網路直播錄製 - DBA 達爾文獎：索引版。

並具體回答您的問題：只要每列具有高選擇性（許多不同的值，每個值在數據庫中只出現幾次） ，每列上的單獨索引都可以工作。在兩個索引範圍掃描之間使用雜湊連接生成的訪問計劃通常效果很好。選擇性低的列（很少有不同的值，每個值在數據庫中出現很多次）對自己的索引毫無意義，查詢優化器將簡單地忽略它們。但是，當低選擇性列與高選擇性列配對時，它們通常會成為很好的組合鍵。

引用自：https://dba.stackexchange.com/questions/12649