分庫分表的中介軟體
比較常見的包括：cobar、tddl、atlas、sharding-jdbc、mycat
cobar：阿里b2b團隊開發和開源的，屬於proxy層方案。早些年還可以用，但是最近幾年都沒更新了，基本沒啥人用，差不多算是被拋棄的狀態吧。而且不支援讀寫分離、儲存過程、跨庫join和分頁等操作。
tddl：**團隊開發的，屬於client層方案。不支援join、多表查詢等語法，就是基本的crud語法是ok，但是支援讀寫分離。目前使用的也不多，因為還依賴**的diamond配置管理系統。
atlas：360開源的，屬於proxy層方案，以前是有一些公司在用的，但是確實有乙個很大的問題就是社群最新的維護都在5年前了。所以，現在用的公司基本也很少了。
sharding-jdbc：噹噹開源的，屬於client層方案。確實之前用的還比較多一些，因為sql語法支援也比較多，沒有太多限制，而且目前推出到了2.0版本，支援分庫分表、讀寫分離、分布式id生成、柔性事務（最大努力送達型事務、tcc事務）。而且確實之前使用的公司會比較多一些（這個在官網有登記使用的公司，可以看到從2023年一直到現在，是不少公司在用的），目前社群也還一直在開發和維護，還算是比較活躍，個人認為算是乙個現在也可以選擇的方案。
mycat：基於cobar改造的，屬於proxy層方案，支援的功能非常完善，而且目前應該是非常火的而且不斷流行的資料庫中介軟體，社群很活躍，也有一些公司開始在用了。但是確實相比於sharding jdbc來說，年輕一些，經歷的錘煉少一些。
所以綜上所述，現在其實建議考量的，就是sharding-jdbc和mycat，這兩個都可以去考慮使用。
sharding-jdbc這種client層方案的優點在於不用部署，運維成本低，不需要**層的二次**請求，效能很高，但是如果遇到公升級啥的需要各個系統都重新公升級版本再發布，各個系統都需要耦合sharding-jdbc的依賴；
mycat這種proxy層方案的缺點在於需要部署，自己及運維一套中介軟體，運維成本高，但是好處在於對於各個專案是透明的，如果遇到公升級之類的都是自己中介軟體那裡搞就行了。
通常來說，這兩個方案其實都可以選用，但是建議中小型公司選用sharding-jdbc，client層方案輕便，而且維護成本低，不需要額外增派人手，而且中小型公司系統複雜度會低一些，專案也沒那麼多；但是中大型公司最好還是選用mycat這類proxy層方案，因為可能大公司系統和專案非常多，團隊很大，人員充足，那麼最好是專門弄個人來研究和維護mycat，然後大量專案直接透明使用即可。
具體是如何對資料庫如何進行垂直拆分或水平拆分的？
水平拆分的意思，就是把乙個表的資料給弄到多個庫的多個表裡去，但是每個庫的表結構都一樣，只不過每個庫表放的資料是不同的，所有庫表的資料加起來就是全部資料。水平拆分的意義，就是將資料均勻放更多的庫里，然後用多個庫來抗更高的併發，還有就是用多個庫的儲存容量來進行擴容。
垂直拆分的意思，就是把乙個有很多欄位的表給拆分成多個表，或者是多個庫上去。每個庫表的結構都不一樣，每個庫表都包含部分字段。一般來說，會將較少的訪問頻率很高的字段放到乙個表裡去，然後將較多的訪問頻率很低的字段放到另外乙個表裡去。因為資料庫是有快取的，你訪問頻率高的行欄位越少，就可以在快取裡快取更多的行，效能就越好。這個一般在表層面做的較多一些。這個其實挺常見的，不一定我說，大家很多同學可能自己都做過，把乙個大表拆開，訂單表、訂單支付表、訂單商品表。
還有表層面的拆分，就是分表，將乙個表變成n個表，就是讓每個表的資料量控制在一定範圍內，保證sql的效能。否則單錶資料量越大，sql效能就越差。一般是200萬行左右，不要太多，但是也得看具體你怎麼操作，也可能是500萬，或者是100萬。你的sql越複雜，就最好讓單錶行數越少。
好了，無論是分庫了還是分表了，上面說的那些資料庫中介軟體都是可以支援的。就是基本上那些中介軟體可以做到你分庫分表之後，中介軟體可以根據你指定的某個字段值，比如說userid，自動路由到對應的庫上去，然後再自動路由到對應的表裡去。你就得考慮一下，你的專案裡該如何分庫分表？一般來說，垂直拆分，你可以在表層面來做，對一些字段特別多的表做一下拆分；水平拆分，你可以說是併發承載不了，或者是資料量太大，容量承載不了，你給拆了，按什麼欄位來拆，你自己想好；分表，你考慮一下，你如果哪怕是拆到每個庫里去，併發和容量都ok了，但是每個庫的表還是太大了，那麼你就分表，將這個表分開，保證每個表的資料量並不是很大。
而且這兒還有兩種分庫分表的方式，一種是按照range來分，就是每個庫一段連續的資料，這個一般是按比如時間範圍來的，但是這種一般較少用，因為很容易產生熱點問題，大量的流量都打在最新的資料上了；或者是按照某個欄位hash一下均勻分散，這個較為常用。
range來分，好處在於說，後面擴容的時候，就很容易，因為你只要預備好，給每個月都準備乙個庫就可以了，到了乙個新的月份的時候，自然而然，就會寫新的庫了；缺點，但是大部分的請求，都是訪問最新的資料。實際生產用range，要看場景，你的使用者不是僅僅訪問最新的資料，而是均勻的訪問現在的資料以及歷史的資料
hash分法，好處在於說，可以平均分配沒給庫的資料量和請求壓力；壞處在於說擴容起來比較麻煩，會有乙個資料遷移的這麼乙個過程
資料庫分庫分表
1 基本思想之什麼是分庫分表？從字面上簡單理解，就是把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存到多個表上。2 基本思想之為什麼要分庫分表？資料庫中的資料量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的資料量也會越來越大，相...
資料庫分庫 分表
分庫的優點是 實現簡單，庫與庫之間界限分明，便於維護，缺點是不利於頻繁跨庫操作，單錶資料量大的問題解決不了。分表的優點是 能解決分庫的不足點，但是缺點卻恰恰是分庫的優點，分表實現起來比較複雜，特別是分表規則的劃分，程式的編寫，以及後期的 資料庫拆分移植維護。實際應用中，一般網際網路企業的路線都是先分...
資料庫分庫分表
簡單了解資料庫分庫分表，以及資料庫的分片 什麼是分庫分表 原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存在到多個表上 為什麼分庫分表 當一張表的資料達到幾千萬時，你查詢一次所花的時間會變多，如果有聯合查詢的花，我想啃根會死在那。分表的目的就在於此，減少資料庫的負擔，縮短查...