SQL Server 索引結構與實戰 (四) : 聚集索引選擇策略 — 兼顧查詢縮小與分頁排序

案例背景：分頁預存程序小資料量效能差

實作「辦公自動化」系統通用分頁 SP，大數據量極快，**但小資料量首頁 1-3 秒、末頁 5-8 秒**，用戶投訴「不如 Access 快」。**根因：排序欄位非聚集索引。**

聚集索引雙重核心價值

1. 最快縮小查詢範圍： 範圍查詢 (如日期區間) 直接定位物理連續頁面，避免全表掃描。
2. 最快排序： 資料物理順序 = 索引順序，**ORDER BY 聚集索引鍵 零排序成本**，分頁取顶 N 极速。

**每表僅能建一個聚集索引**，選擇極其關鍵。

選擇兩難：查詢欄位 vs 排序欄位

• 原設計：聚集索引建在 fariqi (發文日期，精確至日)。優點：時間區間查詢極快。缺點：重複值多，**無法用 MAX/MIN 作分頁書籤**，分頁排序退化。
• 若改建在 ID (主鍵)：分頁排序極快，但**浪費聚集索引於無查詢價值的代理鍵**，時間區間查詢退化為非聚集索引掃描 + 書籤查找。

破解方案：新增高精度時間欄位作聚集索引

1. 新增欄位 created_dt，預設值 GETDATE() (精確至毫秒)。
2. 加 UNIQUE 約束防極罕見碰撞。
3. **將聚集索引建在 created_dt**。

驗證成果

• **分頁速度：大/小資料量均穩定在幾十毫秒甚至 0 毫秒。**
• **時間區間查詢：速度無損耗** (聚集索引天然支援範圍查詢)。
• **唯一書籤：MAX(created_dt)/MIN(created_dt) 完美支援高效分頁算法。**

聚集索引選擇鐵律

1. 建立在**最頻繁用於縮小查詢範圍**的欄位 (如日期、類別、狀態)。
2. 建立在**最頻繁用於排序**的欄位 (如時間、序號)。
3. **最理想：同一欄位同時滿足上述兩條** (如本案 created_dt)。

補充發現：大查詢瓶頸在 CPU 而非記憶體

實測環境 (雙 Xeon 2.4G, 1G RAM, SQL 2000 SP3)：大量查詢時 **CPU 持續 70-100%**，記憶體用量幾無變化。**索引優化降低 CPU 壓力** (減少掃描、排序、Join 運算) 是大數據量效能關鍵。