我這裡說的資料庫主要指mysql
資料庫單庫裡面的資料量越來越大，查詢資料出來的結果所花費的時間變得越來越長；
使用者越來越多，寫入的資料量也變得越來越多，有時會出現延遲，即使我們做了主從讀寫分離，這時候該怎麼辦？
畢竟單台伺服器上的io，cpu，硬碟等等都是有限的，單伺服器上的資源是有限的。
單台伺服器不行，我們可以用多台伺服器，把請求分發到不同的伺服器上，這時候就用到了「分」的思想了。
同理，資料庫的庫和表也是可以切分--分庫分表。把大庫大表變成多個庫表， 同時資料的讀寫也相應的進行了切分。
按大的分類，一般我們有水平切分和垂直切分。
資料表的資料量太巨大，可以進行水平切分表。我們按照某種規則(range, hash等)把資料切分到多張表中。
水平分表
把單張大資料的表按照一定的規則把資料分配到多張資料表中。所有表的結構欄位是相同的。
這樣不僅能控制表的大小，還能提公升查詢和寫入的效能，分解請求的壓力。
比如我們按照range切分表資料，1000w資料分一張表，如果有1500w資料，那麼另外500w資料分到第二張表。
水平分庫
當然我們也可以拆分到多個庫中，比如乙個庫存1年的資料，每個庫分12張表存資料等等方法。根據你的
實際情況進行選擇。
比如我們有的系統中使用的冷熱資料分離，將一些歷史資料遷移到歷史庫中。
垂直切分我們一般按照表字段或業務進行切分。
在資料表上一般我們是按照字段進行切分，就是把一張表的字段拆分成多張表的字段。
或把業務分成不同的業務模組，建立不同的業務模組資料庫。
比如電商，把使用者，商品，訂單獨立建立資料庫。分成多個庫，我們也可以部署到多台伺服器上，增強資料庫
的處理能力。
垂直分表
按照表字段進行切分。
比如資料庫表中的字段比較多，那麼我們建立一張擴充套件表，將不經常使用或者長度較大的字段拆分到擴充套件表中。
當然還有其他的拆分方式。
垂直分庫
在業務上，我們一般會把業務拆分成不同的業務模組，然後根據不同的業務模組建立不同的資料庫，這個就是
垂直分庫。
分庫分表都可以用到上面的2種方式
**有的切分規則上面有提到過
比如1-100000一張表， 100001-200000一張表，每10w資料一張表
比如取使用者id，然後hash取模，分配到不同資料庫
這種切割方式對於日誌的切分一般用的比較多。
比如一張表存放乙個月的資料，一年就是12張表了。
1、資料遷移問題
2、資料擴容問題
3、跨庫join，group by，order等問題
4、事務問題
這部分問題待解決
cobar
阿里巴巴b2b團隊開發的，很少更新
mycat
基於阿里開源的cobar產品而研發，社群開發，現在社群比較活躍
oneproxy
平民軟體開發，不開源的商業中介軟體
kingshard
原360開發團隊的人開發的
vitess
youtube開發的中介軟體
atlas
360團隊基於mysql proxy開發的
maxscale
maridb研發出的中介軟體
mysql route
mysql官方推出的中介軟體
上面的資料庫中介軟體mycat，kingshard都可以好好的研究下，看看他們是如何解決上面的問題的
其他方案就是我們經常所說的 nosql 和 newsql
比如：elasticsearch，mongodb，hbase 等等，這些也是可以好好考慮的方案。
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儲存裡面，這些...