1.為什麼要分庫分表？
分庫分表是兩個不同的概念，分表是為了避免單錶的資料量太大，執行sql時影響語句的執行效能；分庫主要是為了提高系統的併發量。單個庫的併發量最好維持在（1000）左右。
2.資料庫如何拆分？
垂直拆分：例如一張表有10個字段，拆分為一張表3個字段（查詢頻率比較高），和一張表7個字段（查詢頻率比較低）。因為資料庫有快取，這樣快取區能夠儲存更多查詢頻率比較高的字段，進而提高資料庫的效能。
水平拆分：將乙個表拆分成多個表分布到多個資料庫上。一方面提高了系統的整體併發量；提公升了執行的sql語句的效能；
分庫分表中介軟體：協調哪些請求落在哪個資料庫上。常用的分庫分表中介軟體：sharding-jdbc，mycat。
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層方案輕便，而且維護成本低，不需要額外增派人手，而且中小型公司系統複雜度會低一些，專案也沒那麼多；
mysql分表分庫實現 MySql分表分庫思路
一.資料庫瓶頸 1.1io瓶頸 第一種 磁碟讀io瓶頸，熱點資料太多，資料庫快取放不下，每次查詢時會產生大量的io 分庫和垂直分表 第二種 網路io瓶頸，請求的資料太多，網路頻寬不夠 分庫 1.2cpu瓶頸 第一種 sql問題，如sql中包含join，group by，order by，非索引字段條...
MySQL範圍分表分庫 mysql 分表分庫策略
唯一id的生成 下面列舉幾種常見的唯一id生成方案，需要滿足兩大核心需求 1.全域性唯一 2趨勢有序 1.用資料庫的auto increment 自增id 來生成，每次通過寫入資料庫一條記錄，利用資料庫id自增的特性獲取唯一，有序的id。優點 使用資料庫原有的功能，相對簡單 能夠保證唯一 能夠保證遞...
mysql 分庫分表實戰 MySQL分庫分表實戰
為什麼要分庫分表 在大型 中，當使用者量以及使用者產生的業務資料量達到單庫單錶效能極限時，為了支撐業務可持續發展，對於重要的核心業務必然要進行分庫分表來儲存業務資料。對於非核心業務產生的大量資料，例如爬蟲爬取的資訊，論壇產生的資料等，可以考慮把資料儲存在像mongodb這樣的nosql儲存裡面，這些...