基於 Hash 算法的 MySQL 分表策略實戰

分表背景與核心思路

單表資料量過大（如億級）會導致查詢、索引維護、備份恢復效能急劇下降。Hash 分表將資料按某欄位（如 forum_id）經雜湊函數映射到固定數量的子表中，實現資料均勻分佈與水平擴展。

Hash 函數設計範例（PHP）

function get_hash($id) {
    $str = bin2hex((string)$id);      // 轉十六進位字串
    $hash = substr($str, 0, 4);       // 取前 4 字元
    if (strlen($hash) < 4) {
        $hash = str_pad($hash, 4, '0', STR_PAD_RIGHT); // 不足補 0
    }
    return $hash;                     // 如 '3100', '3233'
}

表名組合規則

• 主題表：topic_{hash} → topic_3100
• 回覆表：reply_{hash} → reply_3100

同一 forum_id 的主題與回覆落在同組表，便於關聯查詢。

容量規劃範例

關鍵考量與優化

1. 碰撞可接受

不同 forum_id 可能映射到同一張表（Hash 碰撞），這在分表場景下不需解決，只需確保單表不超容量上限。

2. 選擇高基數欄位

• 優先用 forum_id（數字、唯一、分佈均勻）
• 若用中文名稱 Hash，因字元豐富、碰撞率更低，但產生表數更多，需權衡。

3. 路由層封裝

應用層封裝 getTableName($forum_id, 'topic')，業務代碼無感知，避免 SQL 硬編碼。

4. 擴容策略

• 一致性 Hash / 預分桶（如 1024 桶）+ 邏輯映射表，避免重新洗數據。
• 或採用「雙寫遷移」：新舊規則並行寫入，驗證後切換讀路由。

總結

Hash 分表實作簡單、路由確定性強、無需中間件，適合中小規模水平擴展。核心在於選好分片鍵、設計好 Hash 函數、封裝路由邏輯。大規模場景建議引入 ShardingSphere、Vitess 等中間件。