隨著數據量與訪問量指數級增長，單機資料庫的處理能力終將觸及硬件天花板。本文基於《MySQL性能調優與架構設計》第 12 章核心內容，系統闡述可擴展設計的基本原則，幫助架構師在 Scale Up（縱向擴展）與 Scale Out（橫向擴展）的抉擇中找到最佳平衡點。
| 術語 | 定義 | 資料庫語境 |
|---|---|---|
| Scale（擴展） | 提升系統處理能力的行為 | 增加 CPU/內存/磁盤，或增加節點數量 |
| Scalable（可擴展） | 系統具備通過升級提升能力的特性 | 架構支持無縫擴容，無需重寫代碼 |
| Scalability（擴展性） | 提升能力所需成本（資金/人力/時間）的度量 | 同樣提升 2x 效能，方案 A 需 10 萬，方案 B 需 100 萬 |
核心手段：升級單機硬件（更強 CPU、更大內存、高性能存儲、換更強服務器）
| 優勢 | 劣勢 |
|---|---|
| 架構簡單：單節點，無分佈式複雜度 | 硬件成本指數級增長：高端設備性價比極低 |
| 維護簡單：單實例，無集群管理開銷 | 物理極限：單機 CPU/內存/IO 總有上限 |
| 事務/一致性原生支持：無分佈式事務難題 | 單點故障風險：掛掉全業務停擺 |
| 開發友好：無需改造應用邏輯 | 廠商鎖定：依賴特定高端硬件供應商 |
核心手段：增加廉價 PC Server 節點，構建分佈式集群
| 優勢 | 劣勢 |
|---|---|
| 成本線性增長：廉價機器堆疊，性價比高 | 架構複雜：分片、路由、分佈式事務、一致性 |
| 理論無上限：持續加節點應對增長 | 運維困難：數百節點監控、部署、故障排查 |
| 單點故障影響面小：單節點掛掉僅影響分片 | 應用改造大：需引入中間件、改造數據訪問層 |
階段 1（初創期）：單機 MySQL + 讀寫分離 (Master-Slave)
↓ 寫入壓力增大、單機存儲瓶頸
階段 2（成長期）：垂直拆庫（業務解耦）+ 讀寫分離集群
↓ 單庫單表數據量超大、熱點數據訪問集中
階段 3（成熟期）：水平分庫分表 + 中間件路由
↓ 跨分片事務、全局唯一 ID、分佈式查詢
階段 4（大規模）：分佈式資料庫 / NewSQL / 存算分離架構
核心矛盾：分佈式環境下，跨節點事務極其複雜（兩階段提交、TCC、Saga、最終一致性），效能與開發成本雙高。
-- 訂單服務：按 user_id 分片，保證單用戶訂單、支付、庫存在同分片 -- 避免：訂單按 order_id 分片，用戶按 user_id 分片 → 跨分片事務
-- 原：單事務扣款 + 建單 + 扣庫存 -- 現：T1扣款(本地事務) → T2建單(本地事務) → T3扣庫存(本地事務) -- 應用編排：任一失敗觸發補償邏輯（退款/回滾）
核心妥協：CAP 定理下，分佈式系統通常選擇 AP（可用性+分區容錯），犧牲強一致性（C），轉而追求最終一致性。
| 業務優先級 | 一致性要求 | 技術實現 | 典型場景 |
|---|---|---|---|
| P0 核心 | 強一致（實時） | 同分片事務 / 同步雙寫 / Paxos/Raft | 支付、扣款、庫存扣減 |
| P1 重要 | 最終一致（秒級） | 異步複製 / Binlog 同步 / MQ 可靠投遞 | 訂單狀態流轉、積分變更 |
| P2 一般 | 最終一致（分級） | 定時任務對賬 / 數據同步作業 | 報表統計、推薦特徵、日誌分析 |
鐵律：擴展性不得以犧牲可用性與數據安全為代價。
| 技術 | 一致性 | 故障切換 | 適用場景 |
|---|---|---|---|
| MySQL Replication (半同步) | 最終一致 | 秒級 (MHA/Orchestrator) | 通用生產環境 |
| MySQL Group Replication | 強一致 (多數派) | 亞秒級 (自動) | 核心業務、金融級 |
| InnoDB Cluster | 強一致 | 自動故障轉移 | 企業級高可用 |
| Galera Cluster (PXC) | 強一致 (認證機制) | 自動 | 多主寫入、讀寫分離 |
# 決策樹邏輯
IF (單機硬件未達上限 AND 團隊缺乏分佈式經驗 AND 業務增長可預測) {
CHOOSE Scale Up; // 買更好機器，上優化 SQL、加索引、調參數
} ELSE IF (數據量/並發持續高速增長 AND 團隊有中間件能力) {
CHOOSE Scale Out;
// 關鍵決策點：
// 1. 拆分維度：按什麼鍵分片？(user_id / tenant_id / geo / time)
// 2. 中間件：ShardingSphere / MyCat / Vitess / ProxySQL / 自研
// 3. 遷移策略：雙寫驗證 → 灰度切流 → 全量切換
} ELSE {
CONSIDER NewSQL (TiDB/OceanBase/PolarDB) / 存算分離雲資料庫;
}
可擴展架構設計沒有銀彈，只有基於業務階段、團隊能力、成本預算的動態權衡。核心原則三條線贯穿始終：
MySQL 憑藉開源生態、多引擎架構、成熟復制技術，成為互聯網架構演進的首選基石。掌握這些原則，並在實戰中不斷驗證與調整，是每位資料庫架構師的必修課。
