| 特性 | 聚集索引 | 非聚集索引 |
|---|---|---|
| 資料儲存順序 | 葉節點即資料頁，邏輯順序 = 物理順序 | 葉節點為索引頁，含指標指向資料列 (RID 或叢集鍵) |
| 每表數量 | 僅 1 個 | 最多 999 個 (SQL 2008+) |
| 適合場景 | 範圍查詢、頻繁排序、外鍵、主鍵 | 精確查詢、覆蓋索引、高基數欄位 |
因正文只能有一種排序，故每表僅能有一個聚集索引。
| 動作描述 | 聚集 | 非聚集 |
|---|---|---|
| 欄位經常 GROUP BY / ORDER BY | ✓ | ✓ |
| 返回範圍資料 | ✓ | ✗ |
| 極少或唯一值 | ✗ | ✗ |
| 少量不同值 | ✓ | ✗ |
| 大量不同值 | ✗ | ✓ |
| 頻繁 UPDATE 的欄位 | ✗ | ✓ |
| 外鍵欄位 | ✓ | ✓ |
| 主鍵欄位 | ✓ | ✓ |
測試環境：1000 萬筆資料，近 3 個月 25 萬筆。
| 索引策略 | 查詢語句 | 耗時 |
|---|---|---|
| PK 聚集，無日期索引 | SELECT ... FROM tgongwen | 128 秒 |
| PK 聚集 + 日期非聚集 | WHERE fariqi > DATEADD(day,-90,GETDATE()) | 54 秒 |
| 日期欄位建聚集 | WHERE fariqi > DATEADD(day,-90,GETDATE()) | 2.4 秒 |
結論： 業務查詢核心欄位（如日期）應建聚集索引，ID 身分識別列僅適合非聚集。
同一查詢、同一欄位，聚集 vs 非聚集 差 22 倍。索引類型選擇比單純建索引更關鍵。
測試複合聚集 (日期, 用戶名)：
鐵律： 複合索引前導欄位必須為最高頻查詢欄位，否則索引對該查詢無效。
ORDER BY 聚集索引快 30%+DBCC SHOWCONTIG 檢查碎片，必要時 REBUILD
