關係型資料庫單庫或單錶在資料達到一定量級後，單個節點的就會出現效能瓶頸。通常的做法就是考慮分庫分表。
分庫降低了單點機器的負載；分表，提高了資料操作的效率，尤其是write操作的效率。
(1) user_id為區分，1～1000的對應db1，1001～2000的對應db2，以此類推；
優點：可部分遷移
缺點：資料分布不均
對user_id進行hash（或者如果user_id是數值型的話直接使用user_id 的值也可），然後用乙個特定的數字，比如應用中需要將乙個資料庫切分成4個資料庫的話，我們就用4這個數字對user_id的hash值進行取模運算，也 就是user_id%4,這樣的話每次運算就有四種可能：結果為1的時候對應db1；結果為2的時候對應db2；結果為3的時候對應db3；結果為0的時 候對應db4，這樣一來就非常均勻的將資料分配到4個db中。
優點：資料分布均勻
缺點：資料遷移的時候麻煩，不能按照機器效能分攤資料
就是建立乙個db，這個db單獨儲存user_id到db的對映關係，每次訪問資料庫的時候都要先查詢一次這個資料庫，以得到具體的db資訊，然後才能進行我們需要的查詢操作。
優點：靈活性強，一對一關係
缺點：每次查詢之前都要多一次查詢，效能大打折扣
以上就是通常的開發中我們選擇的三種方式，有些複雜的專案中可能會混合使用這三種方式。 通過上面的描述，我們對分庫的規則也有了簡單的認識和了解。當然還會有更好更完善的分庫方式，還需要我們不斷的探索和發現。
（1）提供分庫規則和路由規則（routerule簡稱rr），將上面的說明中提到的三中切分規則直接內嵌入本系統，具體的嵌入方式在接下來的內容中進行詳細的說明和論述；
（2）引入集群（group）的概念，保證資料的高可用性；
（3）引入負載均衡策略（loadbalancepolicy簡稱lb）；
（4）引入集群節點可用性探測機制，對單點機器的可用性進行定時的偵測，以保證lb策略的正確實施，以確保系統的高度穩定性；
（5）引入讀/寫分離，提高資料的查詢速度；
cobar使用文件（可用作mysql大型集群解決方案）
關係型資料庫分庫分表解決方案
關係型資料庫單庫或單錶在資料達到一定量級後，單個節點的就會出現效能瓶頸。通常的做法就是考慮分庫分表。分庫降低了單點機器的負載 分表，提高了資料操作的效率，尤其是write操作的效率。1 user id為區分，1 1000的對應db1，1001 2000的對應db2，以此類推 優點 可部分遷移 缺點 ...
資料庫分庫分表事務解決方案
隨著時間和業務的發展，資料庫中表的資料量會越來越大，相應地，資料操作，增刪改查的開銷也會越來越大。因此，把其中一些大表進行拆分到多個資料庫中的多張表中。另一方面，在分庫分表以後還需要保證分庫分表的和主庫的事務一致性。這片文章介紹一下 本篇文章是基於非事務訊息的非同步確保的方式來完成分庫分表中的事務問...
表單資料分表解決方案
資料可以根據 對映表找到對應的資料表單 總開關設計 有乙個 總開關，開啟走 分表方案，關閉走不分表 新增租戶功能 提供乙個介面，新增租戶功能 刪除租戶功能 提供乙個介面，刪除租戶功能 資料的增刪改查 刪除資料 查詢資料 修改資料 對映表字段欄位名 說明id id主鍵 tenantid 租戶id fo...