對億級資料表直接排序、JOIN、GROUP BY 易導致 CPU/記憶體/IO 暴衝，系統失去回應。本文歸納生產環境驗證的三大應對策略。
痛點現場還原
- 雙億筆表 JOIN + GROUP BY → CPU 100%、記憶體暴增 5GB、磁碟佇列長度飆升、整機緩慢。
- 統計
SELECT COUNT(*) 耗時 1 分鐘、記憶體漲 5GB、IO 滿載。
- 資料/記錄檔自動成長 1MB 碎片化、DELETE 產生大量記錄、記錄檔暴增爭搶磁碟。
策略一：業務維度拆分 — 將大表化整為零
- 依 時間 (月/季)、地區 (省/市)、業務類型 將億級表拆分為 30+ 小表/分割區。
- 查詢層透過 分割檢視、動態 SQL、應用端路由 僅掃描必要分割區。
- 結果再
UNION ALL 或應用端合併，避免單一巨大掃描。
策略二：資源物理隔離 — 專屬磁碟/實例
- 統計/分析資料庫移至**獨立磁碟陣列 (RAID 10/SSD)**，不與核心 OLTP 爭搶 IO。
- 必要時架設**專屬報表/分析實例** (AlwaysOn 可讀次要複本、邏輯複寫、ETL 至專用 DW)，完全隔離工作負載。
策略三：精細化維運 — 空間、記錄、統計三管齊下
- 空間預留：資料檔預先配置足夠空間，自動成長設為固定 512MB/1GB，避免頻繁擴展碎片。
- 記錄控制：簡單復原模式 + 定期
BACKUP LOG ... WITH NO_LOG (或完整模式 + 高頻記錄備份)，保持記錄檔低水位。
- 統計維護：大表啟用
AUTO_UPDATE_STATISTICS_ASYNC，排程 UPDATE STATISTICS ... WITH FULLSCAN 於低峰期。
- 批次處理：大量 DELETE/UPDATE 分批 (每批 5,000~10,000 列)，配合
WAITFOR DELAY '00:00:00.1' 釋放鎖定、讓記錄檔截斷。
進階：資料表分割 (Table Partitioning)
- 建立 分割函數 (RANGE RIGHT 按日期) + 分割配置 (對應多檔案群組)。
- 配合 分割對齊索引，實現分割消除、平行掃描、分割區切換 (SWITCH) 秒級歸檔/清理。
結語
億級表不可硬抗，「拆分查詢範圍、隔離物理資源、精細化維運」三板斧並舉，才能在有限硬體上穩定支撐海量資料操作。
