Sharding（分片）是解決單庫單表寫入/存儲/查詢瓶頸的水平擴展方案。本文系統闡述 Sharding 應用場景、與 MySQL Partition 區別、核心原理、路由演算法、中間件選型與落地避坑指南。

什麼時候需要 Sharding？

指標	閾值參考	說明
單表行數	> 2000 萬	B+ 樹深度增加、索引維護開銷大、DDL 鎖表時間長
單表大小	> 10-20 GB	備份/恢復/遷移耗時不可接受
QPS/TPS	單實例極限	CPU/IO/網路飽和，垂直擴展無效
業務增長	可預測爆發	提前佈局，避免臨時架構重構

典型場景：MMORPG（玩家 ID 分片）、IM（會話 ID 分片）、電商訂單（買家/賣家 ID 分片）、日誌/埋點（時間+租戶分片）、金融流水（帳戶 ID 分片）。

Sharding vs Partition：本質區別

結論：Partition 是「單機優化」，Sharding 是「分布式架構」。先優化單表 → 單機頂不住再 Sharding。

Sharding 核心三要素

1. 分片鍵選擇——最關鍵決策

• 均勻性：資料、流量均勻分布，避免熱點分片
• 查詢友好：高頻查詢能命中單分片（帶分片鍵）
• 不可變性：分片鍵極少修改（修改需跨片遷移）
• 常見選擇：user_id、tenant_id、order_id、device_id

2. 路由演算法

維度	Sharding (分片)	Partition (分區)
部署範圍	跨多個資料庫實例/物理機	單一資料庫實例內部
擴展能力	水平無限擴展（加實例）	受限於單機資源（CPU/MEM/IO）
透明度	應用/中間件感知路由	SQL 層透明，優化器自動剪枝
事務支援	跨片分布式事務複雜（2PC/TCC/Saga）	原生單機事務，ACID 完整
運維複雜度	高（多實例、Schema 同步、變更協調）	低（單實例管理）
遷移靈活性	可動態遷移分片	REORGANIZE 需鎖表重組

演算法	原理	優點	缺點	適用場景
取模	hash(key) % N	簡單、均勻	擴容需全量遷移	固定分片數、無擴容需求
一致性哈希	環狀哈希 + 虛擬節點	擴容僅遷移 1/N 資料	實現複雜、小叢集傾斜	需頻繁擴縮容
範圍映射	key 範圍 → 分片查表	範圍查詢友好、擴容靈活	易熱點、需維護映射表	時間序列、ID 連續業務
配置表/查表	key → shard_id 映射表	完全可控、支援任意遷移	額外查詢開銷、單點風險	租戶隔離、異構分片

3. 中間件/框架選型

類型	代表	特點	定位
Client-side Library	ShardingSphere-JDBC、MyBatis Sharding	無代理、輕量、應用耦合	微服務、Java 生態
Proxy-side	MyCat、ShardingSphere-Proxy、Vitess、ProxySQL	語言無關、統一入口、運維集中	多語言、legacy 改造、雲原生
Cloud Native	TiDB、PolarDB-X、OceanBase、Spanner	NewSQL、透明分片、強一致分布式事務	新建核心系統、金融級

跨分片查詢與分布式事務挑戰

• 跨分片 JOIN/聚合：中間件拉取各分片結果 → 應用層/Proxy 端合併，效能不可控
• 全局唯一 ID：雪花演算法、段號模式、資料庫自增步長
• 分布式事務：
  • 2PC（XA）：強一致、阻塞、效能差、MySQL 支援有限
  • TCC（Try-Confirm-Cancel）：業務侵入性強、最終一致
  • Saga：長流程編排、補償機制
  • 本地消息表/事務性外發：事件驅動、最終一致

落地避坑指南

1. 分片鍵一錯定乾坤：上線前壓測驗證分布均勻性、查詢命中率
2. 預留擴容方案：從設計之初規劃擴容路徑（如 2 的冪次分片數、一致性哈希）
3. Schema 變更協調機制：統一變更腳本、灰度發布、回滾預案
4. 監控體系：分片級 QPS/RT/錯誤率/延遲/數據傾斜度
5. 測試環境全鏈路覆蓋：包含跨片查詢、分布式事務、擴容演練

總結

Sharding 是「以複雜度換擴展性」的架構決策。沒有銀彈，只有權衡。核心成功因素：分片鍵選對、路由演算法匹配業務增長、中間件選型符合團隊技術棧、分布式事務邊界清晰、運維自動化到位。新專案優先評估 NewSQL（TiDB/PolarDB-X）獲得透明分片能力，存量系統按「讀寫分離 → 垂直拆庫 → 水平分片」漸進演進。