DB2 分區資料庫數據傾斜重新分佈實戰（一）：原理、現象識別與三大觸發場景

DB2 Database Partitioning Feature (DPF) 透過「分區鍵 + Hash 算法 + 分區映射」將數據水平切分至多個邏輯/物理節點，理想狀態下實現線性擴展。然而，分區鍵選型不當、業務數據天然傾斜、節點擴縮容三大因素，極易導致數據分佈不均（Data Skew），拖垮查詢效能與系統吞吐。本文建立識別傾斜、判斷干預時機、選擇重分佈策略的完整決策框架。

分佈機制速覽

1. 分區鍵：建表時指定 `PARTITIONING KEY (col1, col2...)`，決定數據歸屬依據。
2. Hash 算法：DB2 內建雜湊函數將分區鍵值映射至 4096 個 Hash Partition (HP)（0~4095）。
3. 分區映射：4096 HP 循環/加權映射至 Database Partition (DP)（節點）。預設 `UNIFORM` 映射：HP 均勻輪詢分配給各 DP。
4. 數據落地：`INSERT` 時計算 Hash 值 → 查映射表 → 定位目標 DP 寫入。

傾斜現場：從均勻到失衡

測試環境：2 物理機、4 邏輯節點（DP 0~3）。向空表導入 10,240 行，分區鍵為 1~20 循環整數。查詢分佈：

SELECT DBPARTITIONNUM(key), COUNT(*) FROM load_dpf GROUP BY DBPARTITIONNUM(key) ORDER BY 1;

結果顯示：DP 0/2 各 ~3,000 行，DP 1/3 各 ~2,000 行——明顯傾斜。原因：僅 20 個鍵值，Hash 後僅落入少數 HP，映射至固定 DP，無法利用 4096 HP 的分散能力。

三大必須干預場景

REDISTRIBUTE 語法骨架

REDISTRIBUTE DATABASE PARTITION GROUP 
  { UNIFORM | USING DISTFILE  | USING TARGETMAP  | USING TARGETMAP  DISTFILE  }
  [ EXCLUDE  ] [ STATISTICS USE PROFILE ] [ NOT ROLLFORWARD RECOVERABLE ]

參數詳解請參考 IBM Knowledge Center：r0002069.htm。

預設 UNIFORM 模式適用性分析

`UNIFORM` 將 4096 HP 盡量均勻分配給現有 DP，**前提是分區鍵值本身分佈均勻**。若鍵值傾斜（如上例 1~20 循環），`UNIFORM` 無法改善——因為 HP 本身就集中在少數值上。此時必須用 `DISTFILE` 干預 HP 權重，或根治換鍵。

決策流程圖解

1. 發現傾斜/計畫擴縮容 →
2. 確認分區鍵基數與分佈（`RUNSTATS` + `SELECT COUNT(DISTINCT key)`） →
3. 高基數+均勻 → `UNIFORM`；低基數/天然傾斜 → `DISTFILE`（含 `LOAD ANALYZE` 優化）；節點退役 → `TARGETMAP` →
4. 預估數據量、調大日誌、離峰執行 →
5. 驗證分佈、`RUNSTATS`、監控應用延遲。

結語：數據傾斜是 DPF 架構的「先天性疾病」，而非「偶發故障」。DBA 應在建模階段嚴選高基數、低相關性分區鍵；若已上線，建立「分佈健康度定期巡檢（月/季）」機制，將 `REDISTRIBUTE` 納入標準化變更流程，而非等到嚴重熱點才被動救火。