DB2 性能優化六大核心策略：從索引設計到鎖控制的實戰精華

策略一：索引建立時機決定勝負

原則：大量裝載前建索引 → 索引隨數據同步維護，需大日誌空間、速度較慢（可用 NOT LOGGED INITIALLY 緩解）；裝載後建索引 → 需立即 RUNSTATS 更新統計信息，否則優化器不知索引存在，執行計劃退化為全表掃描。

最佳實踐：裝載數據 → CREATE INDEX → RUNSTATS ON TABLE ... AND INDEXES ALL → REBIND 相關包。

策略二：大表上「多節點表空間」+ 索引 = 線性加速

痛點：單節點表空間（如 DIM 空間）僅能利用 2 CPU + 4GB 內存，資源受限。
對策：大表建立分區鍵，放入多節點表空間（如 32 節點），查詢時 32 節點並行掃描、彙總到協調節點，性能指數級提升。索引配合並行掃描，速度更快。

策略三：大批量操作用「不記日誌」模式

ALTER TABLE ... ACTIVATE NOT LOGGED INITIALLY;
-- 或
LOAD ... NONRECOVERABLE;

代價：操作失敗無法回滾，表只能刪除重建。僅適用於可重來的臨時表、階段性裝載表，核心業務表嚴禁使用。

策略四：表級鎖替代行鎖，降低內存壓力

LOCKSIZE TABLE 或 LOCK TABLE ... IN EXCLUSIVE MODE。
收益：鎖數量劇減 → 內存佔用降低 → 減少鎖升級開銷。
適用：獨佔式批量維護窗口、只讀報表鎖定、單用戶維護場景。高併發 OLTP 慎用。

策略五：臨時表「只裝所需、必建索引」

常見錯誤：為了省 JOIN，將大量無用欄位/行塞入臨時表 → 臨時表膨脹 → 掃描變慢。
鐵律：INSERT INTO temp SELECT 只取用到的欄位 FROM ... WHERE 只取用到的行 → 臨時表上建索引 → 後續 JOIN/過濾走索引，速度飛躍。

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

-- 錯誤示範：主表過濾寫在 ON 裡
SELECT * FROM A LEFT JOIN B ON A.id=B.id AND A.status='ACTIVE';

-- 正確：主表過濾放 WHERE，ON 只留關聯+右表過濾
SELECT * FROM A LEFT JOIN B ON A.id=B.id AND B.type='VIP'
WHERE A.status='ACTIVE';

原理：ON 中的主表條件會改變外連接語義，導致結果錯誤且優化器難以下推謂詞，性能雙殺。

總結：優化是系統工程，無銀彈，有原則

六大策略各針對一類典型瓶頸：統計信息時效性、並行度發揮、日誌爭用、鎖內存、臨時表膨脹、外連接語義陷阱。實戰中請結合 EXPLAIN、SNAPSHOT、RUNSTATS 循證調優，切忌盲目套用。數據庫快，業務才穩；業務穩，效益才升。