DB2 優化器統計資訊維護實戰：RUNSTATS、REORGCHK 與 Volatile 表策略

讓優化器看清資料真面目：統計資訊收集與維護完全指南

DB2 採用**成本基礎優化器（CBO）**，其決策品質直接取決於系統目錄中的統計資訊準確度。統計過期或缺失會導致錯誤存取路徑（如錯選 Table Scan 而非 Index Scan），嚴重拖慢查詢效能。本文系統整理統計資訊類型、收集時機、指令語法與特殊場景應對策略。

優化器決策的四大成本因子

• CPU 成本
• I/O 成本
• 系統目錄統計資訊
• SQL 語句本身特徵

核心統計資訊類別

必須執行 RUNSTATS 的 4 大時機

1. 建立新索引後：舊版本常被忽略，V8.2+ 支援 `CREATE INDEX ... COLLECT STATISTICS` 同步更新
2. REORG 重組後：高水位線、頁密度變動需同步統計
3. 資料量變動 10%-20% 以上：大量 Insert/Update/Delete 後
4. 執行 REDISTRIBUTE DATABASE PARTITION GROUP 後：分區資料重分佈

RUNSTATS 完整語法範例

db2 runstats on table db2inst1.staff with distribution and detailed indexes all

• with distribution：收集分布統計（quantiles、frequent values），提升篩選估算精度
• detailed indexes all：詳細索引統計（叢集因子、頁面密度等）

大表採樣統計（V8.1+）

db2 runstats on table big_table tablesample bernoulli (20)

適用數據倉庫超大事實表，前提是資料分布均勻。

Volatile 表策略：應對劇烈波動資料

電信月末匯總表等短期內資料量劇變場景，統計資訊極易失真。標記為 Volatile：

alter table table_name volatile cardinality

• 優化器將**忽略基數統計**，傾向選擇 Index Scan 而非 Table Scan
• 適用「統計資訊只是時間切片，無法反映當前狀態」的場景

REORGCHK：自動判斷是否需重組

db2 reorgchk current statistics on table all
db2 reorgchk update statistics on table all  -- 同時更新統計

依據公式評估表/索引是否達到重組門檻（如 F1、F2、F3 指標）。

實務維護節奏建議

# 典型維護窗口腳本
db2 reorg table schema.tabname
db2 runstats on table schema.tabname with distribution and detailed indexes all
db2rbind db_name -l rebind.log all

先 REORG 整理物理存儲，再 RUNSTATS 更新邏輯統計，最後 REBIND 套用新統計產生最佳存取計畫。

統計資訊是優化器的「眼鏡」，定期清潔、度數精準，查詢效能才能持續在線。