MySQL Sharding 分片架構入門：應用場景、與分區差異、核心原理與中間件選型

單庫單表性能觸頂時，Sharding（分片）將數據按規則分散到多個數據庫實例，實現水平擴展。本文闡述 Sharding 適用場景、與 Partition 區別、核心路由算法、中間件選型（ShardingSphere/ProxySQL/Vitess/TDDL）、分布式事務與全局唯一 ID 解決方案。

一、Sharding 應用場景

• 單表 > 2000 萬行、單庫 > 500GB、QPS > 5000 寫入壓力。
• 聯機遊戲（按玩家 ID 分片）、IM 消息（按會話 ID）、電商訂單（按買家/賣家 ID）、多租戶 SaaS（按租戶 ID）。
• 明確的數據隔離邊界，跨分片查詢比例低（< 10%）。

二、Sharding vs Partition 核心差異

結論：Partition 是單機優化手段；Sharding 是分布式架構手段。兩者可結合：分片間用 Partition 管理歷史數據。

三、核心路由算法

1. 範圍分片：0-1000萬 → shard1, 1000萬-2000萬 → shard2，範圍查詢友好，但易熱點（新範圍寫入集中）。
2. Hash 取模：shard_id = user_id % N，分布均勻，擴容需重分布（Consistent Hashing 緩解）。
3. 一致性哈希：環狀映射，節點增減僅影響鄰近數據，適合緩存/存儲層。
4. 配置表/映射表：shard_map(tenant_id → shard_id)，靈活支援業務變更，需緩存加速。

四、中間件選型對比

五、衍生挑戰與解決方案

• 全局唯一 ID：雪花算法（Snowflake）、數據庫號段模式、UUID v7（時間有序）。
• 跨分片分頁/排序：雙層查詢合併排序、ES/ClickHouse 異構索引支撐。
• 分布式事務：Seata AT/TCC/Saga、本地消息表、事務型消息（RocketMQ/Kafka）。
• 分片遷移/擴容：雙寫同步 → 校驗 → 切流量（Vitess/ShardingSphere 支援在線遷移）。

六、總結

Sharding 是突破單機極限的「核武器」，但帶來架構複雜度指數級上升。能不分片盡量不分片（優化 SQL、讀寫分離、分區表、緩存）；必須分片時，選擇成熟中間件、建立完善治理體系（元數據管理、監控告警、演練預案），將複雜度封裝在基礎設施層，業務層保持無感。