DB2 性能優化六大核心策略：從索引設計到鎖粒度控制

策略一：索引建立時機與統計信息維護

• 數據導入前建索引： 導入過程中索引同步維護，需大量日誌空間，速度較慢。可用 NOT LOGGED INITIALLY 導入減輕日誌壓力。
• 數據導入後建索引： 導入快，但統計信息未更新，優化器不走索引。必須執行 RUNSTATS ON TABLE schema.table AND INDEXES ALL 更新統計，後續查詢才能正確使用索引。

策略二：大表放入多節點分區表空間並建好索引

現有倉庫每節點 2 CPU/4GB 內存。單節點表空間（如維表空間）查詢僅用單節點資源。大表應定義分區鍵，放入多節點表空間，32 節點並行掃描，結果匯總到協調節點，速度指數級提升。並行 + 索引 = 雙重加速。

策略三：大批量操作採用 NOT LOGGED 模式

ALTER TABLE T ACTIVATE NOT LOGGED INITIALLY 配合 WITH EMPTY TABLE 或導入/刪除操作，極大減少日誌爭用，顯著提升吞吐。代價：操作失敗不可回滾，表需重建。適用於可重跑的 ETL 階段、初始化加載等場景。

策略四：表級鎖減少鎖資源消耗

DB2 鎖數量有上限，每把鎖佔內存。大批量操作時，行級鎖易導致鎖升級失敗或內存耗盡。LOCK TABLE T IN EXCLUSIVE MODE 或 ALTER TABLE T LOCKSIZE TABLE 強制表級鎖，減少鎖個數、降低內存佔用、避免鎖升級開銷。適用於獨佔維護窗口、大批量裝載/清洗。

策略五：臨時表只裝「用得上」的列與行

臨時表膨脹是常見性能殺手。嚴格投影（只選所需列）、嚴格過濾（只留所需行）、關鍵列建索引。小表連大表、大表連小表，驅動表越小越好。

策略六：左連接條件寫法謹慎

• ON 子句： 僅放「連接鍵」+「右表過濾條件」。
• WHERE 子句： 放「左表/主表過濾條件」。
• 錯誤示範： 在 ON 中寫左表過濾，會導致優化器誤判連接類型、產生錯誤結果或全表掃描。

-- 正確
SELECT * FROM LEFT_T L
LEFT JOIN RIGHT_T R ON L.ID = R.ID AND R.STATUS = 'A'
WHERE L.CREATE_DATE > '2024-01-01';

-- 錯誤：左表過濾寫在 ON
SELECT * FROM LEFT_T L
LEFT JOIN RIGHT_T R ON L.ID = R.ID AND L.CREATE_DATE > '2024-01-01';

總結檢查清單

1. 大表是否分區並行？索引是否到位？統計是否新鮮？
2. 批量載入是否用 NOT LOGGED？
3. 高併發大事務是否考慮表級鎖？
4. 臨時表/中間表是否精簡？
5. LEFT JOIN 條件是否正確分層？

優化無銀彈，但這六條策略覆蓋了 80% 的常見性能瓶頸場景，建議納入開發規範與 Code Review 清單。