前言：可擴展性的兩條路
- Scale-up (縱向擴展)：換更強 CPU、更大內存、更快 SSD。上限低、成本指數級增長、單點風險大。
- Scale-out (橫向擴展)：增加節點，通過分片、讀寫分離、集群協調實現線性增長。互聯網高併發的唯一出路。
理想狀態：業務無感知、在線擴縮容、流量平滑遷移、零停機。
V1.0 單機單庫：起點
- 一個 MySQL 實例承載所有業務表。
- 瓶頸觸發條件：數據量超單機存儲、熱數據索引超內存、QPS 超單實例極限 (如 3k~5k 混合讀寫)。
- 適用：早期創業、內部管理系統、日活 < 10 萬。
V2.0 垂直拆分：按業務域隔離
- 將低關聯業務表遷移至獨立實例：用戶庫、訂單庫、日志庫、圖片庫...
- 引入 Redis/Memcached 做熱點讀緩存，保護核心庫。
- 瓶頸：單業務單實例仍面臨 V1.0 三大瓶頸。
V3.0 主從架構：讀寫分離
- 主庫承擔寫，從庫分攤讀 (1 主 N 從)。
- 適用「讀多寫少」場景 (如商品瀏覽、資訊流)。
- 瓶頸：寫入量單主無法支撐、從庫同步延遲導致讀舊數據。
V4.0 水平分片：打破單表/單庫極限
- 按 Sharding Key 將大表拆分為 N 個分片，每片 1/N 數據，組成分片集群。
- 每個分片內部仍可採用主從 (V3.0) 保障高可用。
三大路由演算法
| 演算法 | 原理 | 優點 | 缺點 | 典型場景 |
|---|
| Range | 連續區間段 | 範圍查詢高效、擴容只需分裂尾部 | 熱點傾斜 (新用戶集中寫入尾分片) | 自增 ID、時間範圍、訂單號 |
| List | 枚舉值映射 | 業務邏輯直觀、特定群體隔離 | 需維護映射表、新值需變更路由 | 地區、租戶、業務線 |
| Hash | 取模/一致性哈希 | 數據分布均勻、無熱點 | 範圍查詢需全分片掃描、擴容需重新分片 (一致性哈希緩解) | 用戶 ID、設備 ID、Session ID |
分片引入的核心難題與對策
- 非 Sharding Key 查詢：引入「全局二級索引」 (如 Redis 存 `username → user_id`)，接受極低概率不一致 (最終一致性)，寫入雙寫 + MQ 重試保證。
- 分布式事務：跨分片寫入避免使用 XA，採用「本地消息表 + MQ 事務消息」或「Saga 模式」實現最終一致。
- 分片擴容 (Resharding)：最痛點。標準流程：摘從庫 → 停同步 → 記錄增量 Binlog → 靜態數據分裂 → 回放增量 → 切換路由。生產建議初始規劃足夠分片數 (如 1024/4096)，物理遷移而非邏輯分裂，利用 Proxy 熱切換實現零停機。
V5.0 雲原生 / Database as a Service：自動化運維閉環
核心組件：SQL Proxy (如 MyCat、ShardingSphere、Vitess、TDDL)
- 解析 SQL 協議，提取 Sharding Key，路由至目標分片/主從。
- 屏蔽分片細節，應用視角仍是單表。
- 支持讀寫分離、影子表壓測、熔斷降級。
自動化擴縮容架構
- Sync Slave：偽裝為普通 Slave 接入主庫，解析 Binlog 實時按新分片規則寫入目標實例。
- 全量同步 + 增量追趕 → 校驗一致性 → Proxy 熱切換後端連接池 → 下線舊分片。
- 對應用完全透明，實現真正的「飛機空中加油」。
MySQL Fabric / Vitess / PolarDB-X 等雲原生方案
- Fabric (Oracle 官方，已停更) 提供分片管理、高可用、擴容編排。
- Vitess (CNCF 畢業項目，YouTube 驗證) 兼容 MySQL 協議，支撐超大規模分片集群。
- 阿里 PolarDB-X / 騰訊 TDSQL / 華為 GaussDB：云廠商托管的分布式 HTAP 數據庫，內建自動分片、Serverless 彈性。
架構選型決策矩陣
| 業務階段 | 日活/峰值 QPS | 推薦架構 | 關鍵技術投入 |
|---|
| 種子期 | < 1 萬 / < 500 | V1.0 單機 | 備份策略、慢查詢優化 |
| 增長期 | 1~100 萬 / 500~5k | V2.0 垂直拆分 + V3.0 主從 | 讀寫分離中間件、緩存策略 |
| 成熟期 | 100 萬~1 億 / 5k~50k | V4.0 水平分片 + Proxy | 分片中間件、分布式事務、擴容預案 |
| 爆發期/雲遷移 | > 1 億 / > 50k | V5.0 雲原生分布式數據庫 | 托管服務、Serverless、HTAP 混合負載 |
總結
MySQL 架構演進本質是將「狀態」拆散、將「邏輯」下沉、將「運維」自動化。沒有銀彈，只有在正確階段選擇正確複雜度的架構，並在下一個瓶頸到來前完成技術債務償還。建議團隊建立「架構演進路線圖」，每季度評估當前瓶頸與未來 6 個月增長，主動規劃而非被動救火。
