IBM DB2 執行計劃更新全攻略（上）：RUNSTATS/REORGCHK/Volatile 表三板斧

優化器決策的「情報來源」：系統目錄統計信息

DB2 採用基於成本的優化器（CBO），依據四大因子評估存取路徑：CPU 成本、I/O 成本、系統目錄統計信息、SQL 文本本身。統計信息準確與否，直接決定執行計劃優劣。

核心統計信息維度

RUNSTATS：統計信息收集主力軍

四大必跑場景

1. 創建索引後：否則優化器不知索引存在（8.2+ 可 CREATE INDEX ... COLLECT STATISTICS 一體化）。
2. REORG 表後：高水位、頁密度變化，必須同步統計。
3. 數據量變化超 10%-20%：大量 INSERT/DELETE/UPDATE 後。
4. REDISTRIBUTE DATABASE PARTITION GROUP 後：分區數據重分佈，統計失效。

標準命令模板

db2 runstats on table DB2INST1.STAFF with distribution and detailed indexes all

• WITH DISTRIBUTION：收集欄位分布統計（頻率/分位數），提升範圍/連接估算精度。
• DETAILED INDEXES ALL：全量索引詳細統計（聚簇因子、頁密度等）。

大表採樣優化（8.1+）

db2 runstats on table BIG_FACT_TABLE with distribution and detailed indexes all tablesample bernoulli (20)

僅掃描 20% 頁，**前提：數據分布均勻**，否則統計失真反誤優化器。

定時維護鐵律

REORG → RUNSTATS → REBIND 三部曲，按數據變化頻率排程（日/周/月）。

Volatile 表：應對「數據量劇烈波動」的特殊武器

場景：電信月末匯總表，短期內數據量從 0 → 億級 → 歸零，統計信息極不具代表性。
方案：

ALTER TABLE TBL_NAME VOLATILE CARDINALITY

效果：優化器**忽略統計信息中的行數**，**傾向選擇索引掃描而非表掃描**，避免誤判為小表而全掃描。

REORGCHK：用公式判斷是否需要 REORG

db2 reorgchk update statistics on table all

依據統計公式（F1-F8 八條公式）輸出 * 標記，指導是否需 REORG TABLE / REORG INDEXES。

下篇預告

將深入：REBIND 策略、動態/靜態 SQL 計劃緩存機制、EXPLAIN 實戰解讀、優化器參數 (DFT_QUERYOPT) 調優。

核心口訣

建索引跑統計、Reorg後跑統計、數據變兩成跑統計、大表抽樣跑統計、波動表標Volatile、Reorgchk定體檢、三部曲不缺席