DB2 執行計劃優化核心原理與 RUNSTATS 實戰指南（上）

核心原理：基於成本的優化器 (CBO)

DB2 優化器屬於基於成本的優化器（Cost Based Optimizer, CBO）。它不關心「如何查」，只關心「查什麼」。優化器通過查詢成本公式，綜合評估四大因素為每條可能的訪問路徑打分：

• CPU 成本
• I/O 成本
• 系統目錄中的統計信息
• SQL 語句本身的特徵

優化器工作流程

1. 語法校驗：確保 SQL 合法
2. 生成最優計劃：結合當前系統環境與統計信息
3. 翻譯執行：轉為機器指令並運行
4. 返回/緩存結果

統計信息：優化器的「眼睛」

系統目錄視圖中的統計信息直接決定優化器決策質量，主要包括：

此外還有分區/節點組、表空間等信息。

何時必須執行 RUNSTATS？

RUNSTATS 是收集統計信息的核心命令，以下四大場景不可或缺：

1. 創建新索引後

許多開發者創建索引後發現執行計劃未變，原因正是缺少統計信息。DB2 8.2+ 支持創建索引時同步更新統計，舊版本必須手動跑 RUNSTATS。

2. 表重組 (REORG) 後

REORG 會改變高水位線、頁密度等物理存儲特徵，必須跟進 RUNSTATS 更新統計。

3. 數據量發生顯著變化（10%-20%）

大批量增刪改後統計信息失真。對超大表（如數據倉庫事實表），DB2 8.1+ 支持 TABLESAMPLE SYSTEM (20) 抽樣統計，前提是數據分佈均勻。

4. 執行 REDISTRIBUTE DATABASE PARTITION GROUP 後

分區數據庫重新分布數據後，統計信息必須重收集。

RUNSTATS 經典語法示例

對表 DB2INST1.STAFF 及其所有索引收集詳細統計（含分佈）：

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

最佳實踐：REORG + RUNSTATS + REBIND

生產環境建議建立定時任務，按順序執行：

1. REORG TABLE 整理物理存儲
2. RUNSTATS 更新統計信息
3. REBIND 讓靜態 SQL 包基於新統計重新生成計劃

特殊場景：易變表使用 VOLATILE 標記

針對短時間內數據量劇烈波動的表（如電信月末匯總表），統計信息僅代表某個時間點，極易誤導優化器。可將表標記為 VOLATILE：

ALTER TABLE <表名> VOLATILE CARDINALITY

效果： 優化器將傾向選擇索引掃描而非全表掃描，無論統計信息顯示的基數如何。

輔助判斷工具：REORGCHK

IBM 提供 REORGCHK 根據統計公式自動判斷表/索引是否需要重組，可作為維護窗口的決策參考。