包含許多列的SQL Server寬索引包含列

Question

我是否應該小心地將太多的包含列添加到非集羣索引？

據我所知，這將阻止在完全覆蓋的查詢中查找書籤，但計數器我認爲如果列不是靜態的，並且索引的額外整體大小會導致額外的維護索引的額外成本物理讀取。

Answer 1

你在問題中說過：索引中有許多索引和/或多列的風險是，在接收大量CUD（創建/更新/刪除）的數據庫中，維護索引的成本可能變得很重要。操作。

選擇正確的索引是一種藝術，它涉及平衡最常見的用例以及存儲問題（通常是低優先級問題，但在某些情況下非常重要）以及CUD操作的性能問題。

Answer 2

我同意mjv - 沒有真正簡單快速的答案 - 這是一個平衡的行爲。

一般來說，較少但較寬的索引比許多較窄的索引更受歡迎，並且覆蓋索引（包含字段）優於必須進行書籤查找 - 但這只是泛化，而這些通常都是錯誤的： - ）

你真的不能做更多的事情比測試測量：

• 措施您在感興趣的領域的表現
• 然後添加寬，覆蓋指數
• 措施一得到並看看你是否a）在某些操作上獲得加速，以及b）剩餘性能不會受到太大影響

所有的猜測和試圖找出真的沒有幫助 - 測量，做到這一點，再次測量，比較結果。這是你所能做的。

Answer 3

我有兩個答案同意到目前爲止，只想補充兩兩件事：

對於覆蓋索引，SQL Server 2005中引入這使得存儲和使用更有效的INCLUDE clause。對於早期版本，包含的列是樹的一部分，是900字節寬度的一部分，並使索引更大。

使用sp_spaceused時，索引的大小通常也會大於表。數據庫大多是讀取（我看到「讀取85％」的地方），即使寫入很重（例如INSERT查找重複項，DELETE檢查FK，更新WHERE等）。