DB2 數據庫優化六大基石策略：索引、分區、日誌、鎖、臨時表、外連接全維度解析

前言

本文系統梳理 DB2 數據倉庫環境下的六大基石優化策略，涵蓋索引統計維護、多節點並行分區、無日誌批量操作、表級鎖降維、臨時表精簡建模、LEFT JOIN 語義規範，為 DBA 與開發提供統一優化基線。

策略一：索引建立時機與 RUNSTATS 統計同步

• 裝載前建索引： 索引同步維護，日誌壓力大，速度慢。可用 NONRECOVERABLE 裝載規避。
• 裝載後建索引： 統計信息滯後，優化器不走索引。必須 執行 RUNSTATS ON TABLE schema.table AND INDEXES ALL 刷新統計，釋放索引效能。
• 決策建議： 大批量首選「裝載→建索引→RUNSTATS」；小批量高頻可「預建索引+不記錄日誌裝載」。

策略二：大表落地多節點表空間，釋放並行算力

• 單節點瓶頸： DIM 表空間單節點 (2 CPU/4GB)，所有表爭搶有限資源。
• 多節點紅利： 32 節點並行掃描，協調節點匯總，線性加速。
• 關鍵動作： 設計分區鍵 (高基數、均勻、常用連接鍵) → 建多分區表空間 → 表落入分區組 → 配合索引雙引擎加速。

策略三：批量寫入採用 NOT LOGGED 模式，消除日誌爭用

操作： ALTER TABLE ... ACTIVATE NOT LOGGED INITIALLY 或 LOAD ... NONRECOVERABLE。

策略四：表級鎖 (LOCKSIZE TABLE) 降低鎖管理開銷

• 鎖數量有上限，每鎖佔內存。大量行鎖 → 內存壓力 → 鎖升級 → 並發下降。
• 獨佔維護、只讀查詢、批量裝載表 → ALTER TABLE tab LOCKSIZE TABLE。
• 配合 LOCKLIST / MAXLOCKS 參數調優，建立鎖監控告警 (超 70% 告警)。

策略五：臨時表「按需裝載、建索引、無日誌」三原則

1. 精簡數據： 僅插入後續邏輯真正需要的列與行，拒絕全量寬表入臨時表。
2. 針對性索引： 臨時表同樣受益於索引，按關聯/過濾列建立。
3. 無日誌模式： DECLARE GLOBAL TEMPORARY TABLE ... NOT LOGGED。

實測：臨時表數據量降 80% + 索引 → 關聯查詢耗時降 50%~70%。

策略六：LEFT JOIN ON 子句只寫「關聯條件 + 右表過濾」

-- ❌ 錯誤：主表過濾寫在 ON 中，語義異常、優化器誤判
SELECT * FROM main m LEFT JOIN sub s ON m.id = s.id AND m.status = 'A';

-- ✅ 正確：ON 僅關聯 + 右表過濾，主表過濾放 WHERE
SELECT * FROM main m LEFT JOIN sub s ON m.id = s.id AND s.type = 'V'
WHERE m.status = 'A';

違規後果：結果集錯誤 (外連變內連)、謂詞下推失效全表掃描、執行計劃極差。

優化檢查清單 (代碼評審/上線門禁)

結語

六大策略非孤立戰術，而是系統性優化體系：分區給算力、索引給路徑、無日誌給吞吐、表鎖給併發、精簡臨時表給內存、規範外連給正確性。建議將清單固化為團隊《DB2 SQL 開發規範》附件，納入 SonarQube 規則與 CI 門禁，讓優化從「事後救火」轉為「前置設計」。