數據庫水平分表路由算法實戰：MD5 哈希 vs 位移擴展方案對比

數據庫水平分表路由算法實戰

大中型系統為降低單表壓力，常按用戶 UID（唯一自增）水平分表。核心挑戰：均勻分布與平滑擴展。對比兩種主流方案。

方案一：MD5 哈希取前 N 位

function getTable($uid) {
    $ext = substr(md5($uid), 0, 2); // 取前 2 位十六進制
    return "user_" . $ext;          // user_00 ~ user_ff (256 張表)
}

• 優點：UID 遞增但 MD5 離散，數據極其均勻分佈於 256 張表。
• 缺點：無法動態擴展表數量。若單表達 100 萬上限，總容量鎖定 2.56 億；需擴容必須重新遷移全量數據（修改取位數或重新哈希）。

方案二：UID 右移位運算（推薦）

function getTable($uid) {
    // 右移 20 位：每 2^20 = 1,048,576 約 100 萬 UID 一張表
    // sprintf 保留 4 位前導零：user_0000 ~ user_9999 (1 萬張表)
    return "user_" . sprintf("%04d", $uid >> 20);
}

• 核心邏輯：UID >> 20 將 20 位二進制右移，相當於除以 2^20。前 100 萬 UID → 0，次 100 萬 → 1，以此類推。
• 擴展性極強：
  • 4 位後綴支撐 1 萬張表 × 100 萬 = 100 億用戶。
  • 需更多容量 → 改後綴位數（如 6 位支撐 100 萬表 = 1000 億），無需遷移現有數據，新 UID 自動路由新表。
• 通用參數化版本：

  function getTable($uid, $bit, $seed) {
      // $bit: 表後綴位數，$seed: 右移位數
      return "user_" . sprintf("%0{$bit}d", $uid >> $seed);
  }

方案對比總結

工程落地建議

1. 預估峰值用戶量與單表最優容量（如 100 萬行），反推 $seed（移位數）與 $bit（後綴位數）。
2. 配合中間件或應用層封裝路由邏輯，對業務代碼透明。
3. 避免跨分表 JOIN/事務，設計冗余字段或應用層組裝。
4. 監控分表大小分布，發現熱點表（如早期用戶活躍度高）可輔以 UID % N 取模方案作為補充。