MySQL 數據庫分庫分表演進與實踐總結

數據存儲演進三階段

階段一：單庫單表

最基礎架構，如用戶表 user 置於庫 db，所有數據集中查詢。適合早期業務量小、結構簡單場景。

階段二：單庫多表（水平分表）

單表數據量大導致查詢變慢、DDL 鎖表影響讀寫。按規則（如 user_id % 4）拆分為 user_0000、user_0001 等結構相同的表，數據總和保持完整。

階段三：多庫多表（分庫分表）

單機存儲與查詢能力觸達瓶頸，進一步將表分散至多個數據庫實例，實現存儲與計算的水平擴展。

分庫分表核心規則：路由

根據分片鍵（如 user_id）計算目標庫表：

user_id = 123 → 123 % 4 = 3 → 寫入/讀取 user_0003 表

路由邏輯需在應用層或中間件層統一實現，確保寫入與查詢一致性。

分庫分表帶來的挑戰與對策

1. 分片維度衝突

場景：用戶購買商品，按 user_id 分表易查用戶訂單，難查商品銷量；按 item_id 則相反。
對策：

• 雙寫：同步寫入兩套分片表（用戶維度 + 商品維度）
• 引入搜索引擎（Elasticsearch 等）構建倒排索引，滿足多維查詢
• 掃表：僅適用極小數據量，不推薦

2. 跨庫 Join 不可行

關聯表可能分布不同庫，應用層組裝或冗余字段替代。

3. 避免分佈式事務

單事務跨庫修改複雜且效率低，業務設計應盡量避免。

4. 業務聚合部署

同一賣家的商品、交易放同一庫，故障域隔離，避免跨庫強依賴。

主從架構與讀寫分離

一主多從：寫入 Master，讀取分流至 Slave。Slave 可級聯掛載。優勢：大幅提升 QPS。挑戰：

• 複製延遲：高負載、多從庫時加劇
• Master 寫入瓶頸：單點風險，寫壓力大時必須分庫

為什麼 MySQL 單表大了必須分庫分表？

• 文件系統限制：Ext3 對大文件支持差，XFS 可緩解但非根治
• DDL 鎖表：InnoDB B+ 樹僅兩種鎖（葉子節點、非葉子節點），頁分裂、新葉插入會阻塞寫入
• 單表 1000 萬行以下讀寫性能較佳，建議：純數值型 ≤ 800 萬，含字符型 ≤ 500 萬

容量規劃參考

100 庫 × 100 表 × 500 萬 = 5000 億記錄，足支撐大多數業務增長。