分庫分表的常見策略包括垂直分庫、水平分表、水平分庫及組合使用；選擇分片鍵需考慮查詢命中、數據傾斜和擴容便利；查詢問題可通過強制路由、廣播查詢、中間件支持等方式解決；擴容則分為停服和在線遷移兩種方式。具體來說：1. 垂直分庫按業務拆分，水平分表按規則拆分單表，水平分庫將表分散到多個數據庫，組合使用可兼顧兩者優勢；2. 分片鍵優先選用戶id、時間或地域，需避免跨分片查詢、熱點數據和擴容困難；3. 查詢問題通過強制路由定位分片、廣播查詢合并結果、引入中間件處理復雜sql或冗余字段設計來應對；4. 擴容可選擇停服簡單遷移或在線遷移，后者包括準備新結構、遷移數據、同步增量、切換流量并驗證一致性。
在大數據量場景下，mysql 的性能瓶頸往往會暴露出來，尤其是單表數據量超過千萬級甚至更高時，查詢、寫入、鎖競爭等問題都會變得明顯。這時候分庫分表就成了常見的解決方案。
分庫分表的常見策略
分庫分表的核心目標是降低單點壓力，提高系統可擴展性。常見的策略包括：
- 垂直分庫：按業務模塊拆分數據庫，比如用戶相關的放在 user_db，訂單相關的放在 order_db。
- 水平分表：將一張大表按一定規則拆分成多個小表，比如按用戶ID取模。
- 水平分庫：把同一張表的數據分散到多個數據庫中，例如 db0.user_0 和 db1.user_0。
- 組合使用：垂直和水平結合，比如先按業務分庫，再在每個庫內進行水平分表。
選擇哪種方式，主要看你的業務特點和增長預期。
如何選擇分片鍵（Sharding Key）
分片鍵決定了數據如何分布，是非常關鍵的一環。選不好會導致數據傾斜、查詢效率低等問題。
常見的分片鍵有：
- 用戶ID（適用于大部分面向用戶的系統）
- 時間字段（如訂單創建時間，適合按月或年歸檔）
- 地域信息（如城市、區域，適合本地化服務）
選分片鍵時要注意以下幾點：
- 盡量保證查詢能命中一個分片，避免跨庫/跨表查詢
- 避免熱點數據集中在某個分片上
- 考慮未來擴容是否方便，比如取模就不容易擴容，而一致性哈希或者范圍分片更靈活
舉個例子，如果你用用戶ID做分片鍵，那么所有與該用戶有關的操作都可以落在一個分片上；但如果經常需要跨用戶統計，那可能就需要額外處理了。
分庫分表后的查詢問題怎么解決
分庫分表之后，原來簡單的 SQL 可能不能直接用了，尤其是涉及聚合、排序、關聯等操作的時候。
一些常見的應對方式：
- 強制路由：根據分片鍵直接定位到具體分片執行查詢
- 廣播查詢：在所有分片上執行相同語句，然后合并結果（適合讀多寫少、數據量不大的場景）
- 中間件支持：比如 MyCat、ShardingSphere 等，可以自動幫你做路由、合并、排序等
- 冗余設計：對常用聚合查詢字段進行冗余存儲，避免跨分片計算
需要注意的是，跨分片的 JOIN 操作代價很高，應盡量避免，可以通過應用層拼接數據，或者通過異步同步的方式整合到單獨的查詢表中。
數據擴容與遷移怎么做
隨著數據量增長，你可能會面臨擴容的問題。比如原來的 4 個分片不夠用了，要擴展成 8 個。
擴容方案大致分為：
- 停服擴容：簡單但影響用戶體驗，適合早期階段
- 在線擴容：通過中間件或代理實現不停機遷移，適合線上服務
遷移過程一般包括：
- 準備新分片結構
- 全量遷移歷史數據
- 同步增量數據（比如通過 binlog 或消息隊列）
- 切換流量到新分片
- 觀察并驗證數據一致性
這個過程中最怕的就是數據不一致或者切換失敗，所以一定要做好回滾準備和監控機制。
基本上就這些。分庫分表不是一上來就要做的，而是當系統發展到一定階段、單機性能撐不住時才考慮。設計時要考慮好未來的擴展性和維護成本，別為了分而分。
