MySQL 和 MongoDB 作為不同類型數據庫的代表（關系型 vs 文檔型），其分片機制在設計理念、實現方式和適用場景上存在顯著差異。兩者的分片核心目標一致——通過水平擴展（Scale Out）解決單節點存儲容量和性能瓶頸，但因數據模型、事務支持和分布式設計理念的不同，形成了截然不同的分片體系。

一、MySQL 的分片：依賴外部擴展的“間接方案”

MySQL 作為傳統關系型數據庫，設計之初并未原生支持分片（Sharding），其分片能力主要通過中間件或客戶端路由實現。這與其強 ACID 事務、表結構剛性和關聯查詢（Join）依賴密切相關。

1. 核心架構：“中間件 + 多實例”的協同模式

MySQL 分片的典型架構包含三層：

• 客戶端層：應用程序通過 SQL 與中間件交互，無需感知底層分片細節。
• 中間件層：核心組件（如 ShardingSphere-JDBC、MyCat、ProxySQL 等）負責分片策略解析、SQL 路由、結果聚合、跨分片事務協調等。
• 數據存儲層：多個獨立的 MySQL 實例（或主從集群），每個實例存儲部分分片數據（稱為“分片節點”）。

中間件是整個架構的“大腦”，它維護著“分片鍵-分片節點”的映射關系，確保 SQL 語句被路由到正確的分片節點執行。

2. 分片策略：基于表的“邏輯拆分”

MySQL 分片以表為基本單位，通過“分片鍵（Sharding Key）”將一張大表拆分為多份，分散存儲到不同分片節點。常見策略包括：

• 范圍分片（Range Sharding）
  按分片鍵的連續范圍拆分，例如：按時間（訂單表按月份拆分）、按 ID 區間（用戶 ID 1-100萬存分片1，101萬-200萬存分片2）。
  優點：適合范圍查詢（如“查詢近3個月訂單”），數據分布有規律性；
  缺點：易出現“熱點分片”（如最新月份的訂單分片壓力大）。

• 哈希分片（Hash Sharding）
  對分片鍵做哈希計算（如 MD5、CRC32），再按分片數量取模，將數據均勻分散到各節點。例如：用戶 ID 哈希后 % 4，分配到4個分片。
  優點：數據分布均勻，避免熱點；
  缺點：范圍查詢效率低（需掃描所有分片）。

• 列表分片（List Sharding）
  按分片鍵的離散值分組，例如：按地區（華北、華東、華南）拆分用戶表，每個地區對應