IBM DB2 提升並發度的三大實戰策略：隔離級別、鎖機制優化與索引設計

在高並發 OLTP 系統中，鎖衝突是效能瓶頸的主要來源。DB2 提供三種互補的策略來提升並發度，本文透過實例說明各策略的適用場景與配置方式。

策略一：降低隔離級別 — 讀操作避開鎖衝突

使用 WITH UR（Uncommitted Read）子句，讓 SELECT 語句讀取未提交資料，完全不獲取共享鎖：

SELECT * FROM orders WHERE cust_id = 100 WITH UR;

• 適用：報表查詢、非關鍵業務讀取、可容忍髒讀的場景
• 風險：可能讀到未提交（稍後回滾）的資料

策略二：調整鎖檢查時機 — 減少鎖持有時間與衝突

透過 Registry 變數改變 DB2 評估謂詞與鎖的順序：

db2set DB2_EVALUNCOMMITTED=ON   -- 先做謂詞檢查，再加鎖，縮短鎖持有時間
db2set DB2_SKIPINSERTED=ON      -- 跳過未提交的 INSERT 記錄（SELECT/UPDATE 不見該列）
db2set DB2_SKIPDELETED=ON       -- 跳過未提交的 DELETE 記錄（不等待提交，視同已刪除）

生效方式： 設定後需重啟實例（db2stop; db2start）。

策略三：在 WHERE 條件欄位建立索引 — 縮小鎖範圍

精準索引讓 DB2 僅鎖定符合條件的少量列，而非掃描全表加鎖：

CREATE INDEX idx_orders_cust_status ON orders(cust_id, status);
-- 查詢 WHERE cust_id = ? AND status = 'OPEN' 僅鎖定極少數列

• 無索引 → 掃描全表 → 大量列鎖/表鎖 → 高衝突
• 有索引 → 索引範圍掃描 → 僅鎖定符合條件列 → 低衝突

綜合建議

1. 優先從索引設計入手（零風險、效益最大）
2. 業務允許髒讀處套用 WITH UR
3. Registry 變數屬實例級生效，需全盤評估副作用後再啟用
4. 監控 LOCKLIST、MAXLOCKS、鎖等待時間指標驗證優化成效