您现在的位置：程式碼之家 >> 數據庫知識 > >> MySQL 資料庫 >> MySQL 綜合教學

MySQL 性能調優與架構設計第 14 章：數據切分 (Sharding) 垂直/水平/混合架構與中間層整合方案

編輯：MySQL 綜合教學

從單機到叢集：MySQL 數據切分 (Sharding) 完整架構指南

本文摘自《MySQL性能調優與架構設計》第 14 章，系統闡述當複製架構遇到寫入瓶頸、單表過大時，如何通過**垂直切分 (按業務模塊)**、**水平切分 (按邏輯鍵)**、**混合切分** 將數據分散到多實例，並解決切分後的路由、事務、跨分片 Join/分頁、中間層選型等核心難題。

14.1 什麼是數據切分

定義：依特定規則，將同一資料庫的數據分散存放到多個資料庫實例 (主機)，分散負載、提高可用性 (單點故障只影響部分數據)。
兩大模式：
- 垂直切分：按表/Schema 分庫，不同業務模塊獨立實例。規則簡單、耦合度低時最適合。
- 水平切分：同一表按字段值 (如 user_id % N、時間範圍、Hash) 拆分到多庫。解決單表超大、高併發寫入瓶頸。
實戰常結合：先垂直拆模塊，再對核心大表水平拆分。

14.2 垂直切分實戰與優缺點

案例：社交系統四大模塊拆分

用戶模塊：user, user_profile, user_group, user_photo_album
群組討論：groups, group_message, group_message_content, top_message
相冊：photo, photo_album, photo_album_relation, photo_comment
事件：event

雖模塊間有關聯 (如群組-用戶、相冊-用戶)，但關聯鍵單一 (user_id/group_id)，可在**應用層透過介面組裝**完成 Join，避免跨庫 Join。

垂直切分優缺點

優點	缺點
規則清晰、實施容易、維護定位快	跨模塊 Join 需應用層組裝、增加應用複雜度
業務隔離、故障域縮小	單表過大時無法解決寫入瓶頸
資源分配靈活 (核心模塊給強機器)	切分過度導致系統過度碎片化、難維護

14.3 水平切分實戰與優缺點

切分鍵選擇原則

核心表多以 **用戶 ID (user_id)** 為關聯中樞 → 採用 user_id % N 取模分片。
論壇系統以 **板塊 ID (forum_id)** 切分。
時間序列數據 (日誌、事件) 按 **時間範圍** 切分 (如按月/季)。

案例：按 user_id 取模 2 分片

所有與用戶關聯的表 (除 groups 無直接 user_id) 均按 user_id % 2 分片，同一用戶數據落在同一分片，**分片內 Join 零跨庫**。groups 表獨立垂直切出。

水平切分優缺點

優點	缺點
分片內 Join 完整、事務簡單 (單分片)	切分規則抽象難、難以覆蓋所有查詢場景
線性擴展、無單表瓶頸	運維定位難、手工排查成本高
應用改動相對小 (只加路由邏輯)	模塊耦合度高時遷移困難

14.4 混合切分：垂直 + 水平協同演進

隨負載增長：先垂直拆模塊 → 核心模塊單表仍大 → 在該模塊內水平拆分。
示例架構演進：

垂直拆 4 庫 (用戶、群組、相冊、事件)。
用戶庫按 user_id % N 水平拆；群組庫按 group_id 拆；相冊庫按 album_id 拆；事件庫按時間拆。
形成多維度分片矩陣，各分片獨立擴展。

優點：發揮兩者優勢、極致擴展性；缺點：架構最複雜、運維成本最高。

14.5 切分後數據整合方案：中間代理層選型

應用直連多分片不可維護，**必須引入中間代理層** 對應用透明化。

主流開源代理對比

代理	語言	核心功能	適用場景
MySQL Proxy	C + Lua	連接路由、SQL 分析/過濾/改寫、負載均衡、基礎 HA	需深度定制 SQL 改寫、Lua 腳本能力強的團隊
Amoeba for MySQL	Java	垂直/水平路由規則 (XML)、讀寫分離、負載均衡、HA、MySQL 協議兼容	純 MySQL 環境、偏好 XML 配置、需現成路由規則引擎
Amoeba for Aladdin	Java	多異構數據源 (MySQL/Oracle/DB2) 聯合路由、MySQL 協議前端	異構數據庫整合、統一 SQL 入口
HiveDB	Java	基於 Hibernate Shards、僅水平切分、自建冗余/HA、並行多片查詢合併	ORM 深度整合、Hibernate 技術棧
其他	-	HSCALE (MySQL Proxy 增強)、Spock Proxy (Rails)、Pyshards (Python)	特定技術棧偏好

Amoeba 配置核心 (XML)

amoeba.xml：數據源、代理參數、讀寫分離、負載均衡。
rule.xml：垂直/水平路由規則 (如 user_id % 2)。
functionMap.xml / ruleFunctionMap.xml：自定義路由函數 Java 類映射。
已知限制：**不支援分散式事務**、**線上管理介面較弱** (開發中)。

14.6 切分帶來的三大經典難題與應對策略

1. 分散式事務

問題：跨分片業務需原子性，MySQL 5.0+ 僅 InnoDB 支援 XA 事務，效能差、異常處理複雜。
應對：**應用層拆解為多個本地事務 + 補償機制 (TCC/Saga)**，由應用保證最終一致性，避免資料庫層面 XA。

2. 跨分片 Join

問題：驅動表與被驅動表在不同分片，單 SQL 無法完成。
應對：應用層**先查驅動表取結果集 → 依結果集 IN 列表查被驅動表 → 記憶體中合併**。犧牲單查詢延遲換取系統整體擴展性。Federated 引擎雖可跨實例 Join 但結構變更不同步風險大，**不推薦生產使用**。

3. 跨分片排序分頁

問題：ORDER BY ... LIMIT 涉及多分片，單片 Top-N 合併後非全局 Top-N。
應對：應用層**並行查各分片 Top-N → 記憶體合併排序取最終 Top-N**。比 Join 更易並行、效能損失更小。同樣消耗應用端記憶體/CPU。

14.7 小結

數據切分是 MySQL 突破單機寫入/存儲上限的核心手段。**垂直拆業務、水平拆數據、混合演進**，配合 **Amoeba/MySQL Proxy 等中間層** 實現路由透明化，**應用層吸收跨分片 Join/分頁/事務複雜度**，是大型互聯網架構的標準演進路徑。切分規則設計、中間層選型、運維體系建設三位一體，才能真正落地。