MySQL 分庫分表常用策略與核心架構圖解

一、分庫策略

1.1 按業務域垂直分庫

將低耦合業務拆分為獨立實例/數據庫，物理隔離資源、故障域、權限域。

1.2 按地域/租戶水平分庫

同一套表結構，按城市/大區/租戶 ID 分佈到不同實例。

• 如：db_order_bj, db_order_sh, db_order_gz 或 db_tenant_1001, db_tenant_1002
• 適用：多租戶 SaaS、全國業務強地域隔離、法規要求數據落地。
• 挑戰：跨庫查詢、全局唯一 ID、Schema 變更同步、運維複雜度 N 倍。

二、分表策略

2.1 按業務主鍵 Hash 取模

-- 按月分表
t_log_202401, t_log_202402, t_log_202403...
-- 按日分表 (極大流量)
t_access_20240101, t_access_20240102...

• 優點：天然支持時間範圍查詢、歷史歸檔刪除極快 (DROP PARTITION/TABLE)、熱冷分離自然。
• 缺點：當前熱表寫入壓力集中、跨月/跨日查詢需 UNION。

2.3 複合分表 (Hash + 時間)

寫入 → Master → Binlog (ROW) → 多 Slave 異步/半同步複製。
讀取 → VIP/LVS → Slave 池 (權重輪詢/最少連接)。
工具：ProxySQL、MaxScale、MyCat、ShardingSphere-Proxy。


3.2 MHA / Orchestrator 自動故障切換

監控 Master 健康，秒級故障檢測 → 選最新從庫提升 → 重寫其它從庫指向 → 應用無感切換 (VIP 漂移 / DNS 更新 / Proxy 後端切換)。


3.3 PXC (Percona XtraDB Cluster) / Galera 多主同步

多節點同步複製 (認證式)，任意節點可讀寫，強一致性 (犧牲部分寫性能)。
適合跨機房高可用、讀寫負載均衡、無單點寫瓶頸。


四、架構選型建議

業務規模
分庫策略
分表策略
高可用方案
中間件

單機可支撐
不分庫
不分表
雙機熱備 (MHA/Keepalived)
無 / ProxySQL
多業務域、單庫瓶頸
垂直分庫
大表 Hash 分表
各庫獨立一主多從
ShardingSphere / MyCat
單表 > 5000W / TB 級
垂直 + 水平分庫
Hash + 時間複合分表
PXC / 多主多從
Vitess / TDDL / 自研 Proxy
多租戶 / 多地域
租戶/地域分庫
租戶內 Hash 分表
各實例獨立 HA
路由層感知租戶


五、避坑指南

全局唯一 ID：雪花算法 / 段號模式 / TiDB auto_random，避免自增 ID 衝突。
分布式事務：能不用盡量不用；必須用 → Seata AT 模式 / 本地消息表 / 事務性 MQ (RocketMQ 事務消息)。
跨分片 JOIN/排序/分頁：推至應用層組裝 / 引入 OLAP 引擎 (ClickHouse/Doris) 做寬表查詢。
Schema 變更：pt-online-schema-change / gh-ost 在線 DDL，分片逐個滾動執行。
擴容預案：預留 1024/4096 邏輯分片，物理遷移而非邏輯分裂，配合 Proxy 熱切換。


總結
分庫分表是**將大問題拆解為多個小問題**的藝術。核心原則：**垂直拆分隔離業務域、水平拆分打破單機極限、時間維度天然歸檔、Hash 維度均勻分佈**。架構演進要跟上業務增長節奏，提前 6 個月佈局下一階段方案，避免「帶病狂奔」。