MySQL 分布式存儲架構演進指南
面對 SaaS 平台數據增長、租戶隔離、擴容無感知等挑戰，本文梳理從單庫到分布式存儲的演進路徑：垂直分庫 → 水平分表 (分片) → 原生分區 → Proxy 中間件透明路由，並對比主流分片中間件優劣，提供架構選型參考。
演進四階段
階段 0：單庫單表 (單體應用)
- 所有業務表在一個 MySQL 實例。
- 瓶頸：連接數、IOPS、存儲、備份窗口、Schema 變更鎖表。
階段 1：垂直分庫 (微服務化)
- 按業務域拆分：用戶庫、訂單庫、商品庫、日誌庫...
- 不同庫部署在不同實例/機器，物理隔離資源。
- 應用層路由：Service A 連 User DB，Service B 連 Order DB。
- 優點：單庫壓力降低、故障域隔離、團隊自治。
- 缺點：跨庫事務 (分佈式事務/最終一致性)、跨庫 Join 不可能、運維實例數增長。
階段 2：水平分表 (分片 Sharding)
- 單表超過 2000 萬行 / 20GB 時拆分：
order_0...order_63 (64 分片)。
- 分片鍵選擇：
user_id % 64 (Hash)、create_time (Range)、一致性哈希。
- 路由層選擇：
- 客戶端 SDK (ShardingSphere-JDBC, MyCat-Client)：應用內路由，無中間件單點，但多語言需多端實現。
- Proxy 中間件 (MySQL Router, ProxySQL, ShardingSphere-Proxy, Vitess vtgate)：統一 SQL 入口，異語言透明，但引入網絡跳數與單點 (需 HA)。
- 課題：分布式主鍵 (Snowflake/段號)、分布式事務 (Seata/2PC/TCC)、全局二級索引、分頁查詢、聚合查詢、擴容遷移。
階段 3：MySQL 5.1+ 原生分區
PARTITION BY RANGE/LIST/HASH/KEY 替代手工分表。- 優點：DDL 自動化、分區裁剪、單表邏輯、InnoDB 支援、工具生態 (pt-online-schema-change 兼容)。
- 缺點：分區鍵必須包含在主鍵/唯一鍵中、全局索引不支援 (需應用層維護)、單機極限未破 (仍受限於單實例 CPU/IO/內存)。
- 適用：單實例內大表管理、歷史數據歸檔、範圍查詢優化。
階段 4：新一代分布式 SQL (NewSQL)
- TiDB、OceanBase、PolarDB-X、CockroachDB：MySQL 協議兼容、強一致分佈式事務、自動分片均衡、彈性擴縮容、HTAP 混合負載。
- 遷移成本：應用無感 (協議兼容)、數據遷移工具 (DM/Lightning)、驗證周期長。
中間件選型對比 (2024 視角)
| 中間件 | 架構 | 分片算法 | 讀寫分離 | 分布式事務 | 生態/成熟度 | 推薦場景 |
|---|
| ShardingSphere-Proxy | Proxy | Hash/Range/Complex/Hint | ✅ | XA/BASE/Seata | Apache 頂級、Java 生態強 | Java 微服務、異構數據源 |
| ProxySQL | Proxy | Query Rules/Regex/Lua | ✅ (內建) | ❌ | C++ 高性能、運行時動態配置 | 讀寫分離、查詢改寫、快取、熔斷 |
| MySQL Router | Proxy | ❌ (僅路由 InnoDB Cluster) | ✅ | ❌ | 官方 GA、InnoDB Cluster 標配 | InnoDB Cluster / ReplicaSet |
| Vitess (vtgate) | Proxy + VTTablet | Range/Hash/External | ✅ | 2PC (有限) | YouTube/Slack 驗證、CNCF 畢業 | 超大規模分片、K8s 原生 |
| MyCat | Proxy | Hash/Range/Mod/Enum | ✅ | ❌ | 國產早期、社區活躍度下降 | 存量維護、簡單分片 |
| Atlas (360) | Proxy | 簡單 Hash | ✅ | ❌ | 已停更 | 不建議新項目 |
架構選型決策樹
- 單表 < 2000萬 / < 20GB → 單庫優化 (索引、SQL、配置、讀寫分離) 即可，勿過度設計。
- 業務域明確、跨域關聯少 → 垂直分庫 + 微服務，各庫獨立演進。
- 單表巨大、高併發、需線性擴展 → 水平分片 + Proxy (ShardingSphere/ProxySQL/Vitess) 或遷移 NewSQL (TiDB/OceanBase)。
- 單實例內大表、範圍查詢、歷史歸檔 → 原生分區
PARTITION BY RANGE 替代手工分表。
- 異構數據源、多租戶、SQL 改寫、快取、熔斷 → ProxySQL (單機高性能) + ShardingSphere (分片邏輯)。
核心原則
- 業務驅動架構：不要為了分片而分片，先優化單表、讀寫分離、垂直拆分。
- 分片鍵即命運：選錯分片鍵 = 全鏈路痛苦 (跨分片 Join、熱點、遷移地獄)。核心實體 ID (user_id/tenant_id) 通常是最佳分片鍵。
- 中間件即契約：SQL 兼容性、Hint 語法、分布式事務語義、監控指標、升級策略，上線前必須全鏈路驗證。
- 遷移預案先行：雙寫、同步校驗 (
pt-table-checksum)、灰度切流、回滾方案，無預案不遷移。
- 可觀測性優先：分片後 SQL 路由、執行計畫、延遲分布、錯誤率、分片均衡度，全鏈路可視才敢睡覺。
分布式存儲架構沒有銀彈，只有在特定業務階段、團隊能力、成本預算下的最優解。從垂直分庫開始，以原生分區過渡，引入 Proxy 透明化路由，最終評估 NewSQL 替代，是風險最低、收益最大的演進路徑。
