MySQL 架構擴展之道：分區分庫與負載均衡實戰架構

單機極限與擴展必然性

單 MySQL 實例受限於單進程多線程模型，無法充分利用多核 CPU；寫入吞吐受限於單主架構；存儲容量受限於單機磁盤。當 QPS、存儲、併發突破單機上限，**水平擴展**成為唯一出路。

一、數據分區（Sharding）策略

1. 水平分區：按業務鍵將行分散到多實例

核心決策：分區鍵選擇 —— 直接決定負載均勻度、查詢路由複雜度、跨分區事務難度。

• 用戶 ID 取模：shard_id = user_id % N。優點：簡單、負載均勻。缺點：擴容需遷移數據、跨分區查詢需聚合。
• 用戶名哈希：shard_id = hash(username) % N。優點：字符串鍵也能均勻。缺點：同樣面臨擴容遷移。
• 範圍分區：0-1000萬 → shard1, 1000萬-2000萬 → shard2。優點：擴容只需新增分區、範圍查詢高效。缺點：熱點數據集中（新用戶集中在最新分區）。
• 業務屬性分區：按地域、租戶、業務線劃分。優點：物理隔離、合規友好。缺點：負載可能極度不均。

避坑指南：

1. 分區鍵一旦確定，**極難變更** —— 需全量數據重分布
2. 嚴禁跨分區分布式事務（兩階段提交性能極差），業務設計上隔離跨分區寫入
3. 全局唯一 ID 生成：雪花算法 / 數據庫段號模式 / UUID，避免自增 ID 衝突

2. 功能分區：按業務域拆分實例

• 核心交易庫（高一致、高可用）
• 日志/審計庫（寫多讀少、可降級）
• 報表/數倉庫（只讀、大查詢、可延遲同步）
• 全文搜索庫（同步至 Elasticsearch/Solr）
• 緩存層

不同域採用不同存儲引擎、不同高可用策略、不同備份策略，互不干擾。

二、讀寫分離與主從複製拓撲

經典架構：一主多從

          ┌─────────────┐
寫入 ────▶│   Master    │
          └──────┬──────┘
                 │ Binlog 異步/半同步複製
       ┌─────────┼─────────┐
       ▼         ▼         ▼
    Slave1    Slave2    Slave3
     (讀)      (讀)      (讀)

關鍵問題：複製延遲導致讀舊數據

用戶發帖 → 寫 Master → 立即讀 Slave → **可能讀不到剛發的帖**。

解決方案對比

三、中間層路由與代理方案

四、負載均衡：從網絡層到應用層

硬件負載均衡（F5、A10）僅做 4 層轉發，**不感知 MySQL 協議狀態**（如從庫掛掉、複製延遲、只讀狀態）。軟件方案更優：

• LVS (IPVS)：內核級 4 層負載，高性能、穩定，算法：RR/WRR/LC/WLC/LBLC/LBLCR/DH/SH
• Keepalived + LVS：提供健康檢查、VIP 漂移、高可用
• HAProxy：7 層代理，支援 MySQL 協議健康檢查、讀寫分離、TLS 終結
• ProxySQL：前述中間層本身即含負載均衡功能（按權重、最少連接、延遲）

五、架構演進路線圖

1. 單機優化：索引、SQL、參數、硬件（SSD、大內存）
2. 讀寫分離：一主多從，解決讀擴展
3. 功能分區：業務域拆庫，隔離故障域
4. 水平分片：單表 > 2000萬/單庫 > 500GB 時啟動
5. 中間層接管：ProxySQL/Vitess 統一路由、治理
6. 多活/異地災備：雙主/多源複製、GTID、Binlog 同步工具

六、生產落地核心清單

1. 分片鍵選型經過壓測驗證，負載均勻度 > 90%
2. 全局 ID 生成方案無衝突、單調遞增（利於索引）
3. 跨分片查詢 < 5%，且有明確聚合策略
4. 讀寫分離路由邏輯經過混沌工程驗證（殺從庫、網絡分區）
5. 監控覆蓋：複製延遲、QPS/延遲/錯誤率分片維度、連接池狀態
6. 變更流程：Schema 變更走線上工具，分片擴容有演練預案

總結

MySQL 擴展無標準答案，**「業務驅動架構，簡單優於複雜」**。優先用好單機，再讀寫分離，再功能分區，最後才水平分片。每一步都要有明確的性能指標觸發線、回滾預案、監控儀表盤。切忌為分片而分片，過度設計是架構最大的債。