SQL Server分頁優化：叢集索引是關鍵

現象：通用分頁存儲過程在小數據量下反而變慢

實測發現：第三版分頁存儲過程在大數據量（百萬筆）表現優異，但在小數據量（僅幾頁）時，前幾頁查詢需1-3秒，最後一頁5-8秒，甚至不如未優化版本，用戶直呼「不如Access快」。

根因：排序欄位非叢集索引

叢集索引有兩大優勢：最快縮小查詢範圍、最快排序。分頁本質是「排序後取區間」，若排序欄位無叢集索引，每次分頁都需全表掃描+排序，開銷固定，與資料量無關，故小表反而顯慢。

矛盾：查詢範圍欄位 vs 排序欄位

• 原設計以fariqi（發文日期，精度「日」）為叢集索引 → 利於時間段篩選，但重複值多，無法用MAX/MIN做分頁定位。
• 若改用ID主鍵為叢集索引 → 分頁極快，但失去時間篩選優勢，浪費寶貴的叢集索引資源。

解決方案：新增高精度時間欄位做叢集索引

1. 新增欄位CreateTime，預設值GETDATE()（精度毫秒）。
2. 於此欄位建立UNIQUE約束（防極罕見重複）。
3. 將叢集索引移至CreateTime。

效果：同時滿足「時間段快速篩選」與「唯一排序鍵分頁」，大小數據量分頁穩定在幾十毫秒甚至0毫秒。

叢集索引選型黃金法則

1. 最頻繁用於縮小查詢範圍的欄位。
2. 最頻繁用於排序的欄位。

硬體觀察：CPU才是瓶頸

大數據量測試中，CPU持續100%（P4 2.4）或90%（雙Xeon 2.4G），記憶體佔用幾無變化。優化索引遠比單純加記憶體有效。