SQL Server 索引管理六大鐵律：在效能提升與維護成本間尋找平衡點

索引是加速查詢的利器，但「天下沒有免費的午餐」。盲目建立索引反而拖垮寫入效能、佔用空間、增加維護負擔。本文提煉六大索引管理鐵律，助您建立科學的索引策略，在查詢加速與系統開銷間找到最佳平衡點。

鐵律一：認清索引的隱形成本，尋找投資報酬平衡點

• 建立成本：掃描全表、排序、寫入索引頁面，大表耗時極長。
• 維護成本：每次 INSERT/UPDATE/DELETE 都需同步調整索引結構 (B-Tree 分裂/合併)，寫入越頻繁、索引越多，CPU/I/O 壓力指數級上升。
• 空間成本：非叢集索引獨立儲存鍵值+RowLocator，寬索引、多索引可超過基底表大小。
• 最佳化器負擔：索引越多，查詢最佳化器評估替代方案時間越長 (雖通常微秒級)。

策略：以工作負載為導向，僅為高頻、高成本查詢建立索引；定期用 sys.dm_db_index_usage_stats 識別未使用索引並移除。

鐵律二：低查詢頻率欄位、低選擇性欄位 (高重複值) 勿建單一索引

• 查詢不涉及：如員工表從不依「身分證字號」查詢，建索引純屬浪費。
• 選擇性極低：性別 (M/F)、狀態碼 (0/1/2)、布林欄位。最佳化器判斷掃描基底表比走索引+Key Lookup 更便宜，**拒絕使用索引**。
• 替代方案：FILTERED INDEX (WHERE 子句限定熱門值)、複合索引前導欄位、INCLUDE 覆蓋索引。

鐵律三：範圍查詢高頻欄位優先建立索引 (特別是叢集索引)

• 常見場景：日期區間 (訂單日期、交易時間)、編號區間、價格區間。
• 索引天然有序，範圍掃描只需定位起點順序讀取，**極大減少頁面存取**。
• 叢集索引鍵若為範圍查詢欄位 (如 OrderDate)，資料物理順序即邏輯順序，效能最優。
• 搭配 TOP N 限制回傳筆數，避免大範圍掃描回傳海量資料給應用層。

鐵律四：複合索引遵循「等值優先、範圍在後、選擇性高在前」排序原則

-- 範例：WHERE Status = 1 AND OrderDate BETWEEN '2023-01-01' AND '2023-12-31' AND CustomerId = 100
-- 最佳索引順序：(Status, CustomerId, OrderDate)
-- Status: 等值、高選擇性 (假設)
-- CustomerId: 等值、高選擇性
-- OrderDate: 範圍、置於最後

• 等值條件 (=, IN) 可精確定位索引區間。
• 範圍條件 (>, <, BETWEEN, LIKE 'abc%') 只能用於索引前導欄位已定位後的後續掃描。
• 若查詢未使用複合索引**第一欄**，索引**完全不會被使用** (Index Skip Scan 不支援)。

鐵律五：大表謹慎使用覆蓋索引，小心 INCLUDE 欄位過多反拖慢寫入

• 覆蓋索引：查詢所需欄位全在索引中 (鍵值 + INCLUDE)，避免 Key Lookup 回表，讀取極快。
• 代價：INCLUDE 欄位雖不參與排序，但佔用索引頁面空間，增加寫入 I/O、記憶體壓力、備份體積。
• 判斷標準：查詢頻率極高、延遲敏感、回傳欄位固定少數 → 適合覆蓋。反之，寫入頻繁、查詢多樣 → 僅索引鍵值 + 必要 INCLUDE。

鐵律六：建立索引維護機制：定期重建、統計資訊同步、監控碎片與使用率

• 碎片整理：avg_fragmentation_in_percent > 30% → REBUILD (ONLINE=ON)；5-30% → REORGANIZE。
• 統計資訊：索引重建自動更新統計資訊；重組後需手動 UPDATE STATISTICS 或 sp_updatestats。
• 使用率監控：sys.dm_db_index_usage_stats 追蹤 user_seeks, user_scans, user_lookups，長期為 0 的索引候選移除。
• 遺失索引提示：sys.dm_db_missing_index_* DMV 提供最佳化器建議，但需人工驗證合併相似建議、評估寫入影響。

總結：索引管理決策流程圖

新查詢效能問題
    ↓
分析執行計畫 (Missing Index Hint / Scan / Key Lookup)
    ↓
識別核心篩選/聯結/排序欄位
    ↓
評估欄位選擇性、查詢頻率、寫入頻率
    ↓
設計索引 (單欄/複合/覆蓋/篩選) → 測試環境驗證執行計畫變化
    ↓
上線 → 納入維護排程 (重建/統計/監控)
    ↓
定期審視使用率 → 移除無效索引