前言
內容來源
本文內容均來源於網絡,涉及地址
爲什麼要分庫分表（個人理解，希望能與大家共勉）
https://blog.csdn.net/a992795427/article/details/84949760
淺談分庫分表
https://blog.csdn.net/huangshanchun/article/details/78885765
分庫分表之sharding-jdcb
http://www.cnblogs.com/mr-yang-localhost/p/8120543.html
關於分庫分表
其實分庫分表是牽扯到高併發的，因爲分庫分表無非來說就是爲了支撐高併發、數據量大的問題。
什麼是分庫分表?
將單個庫拆分成多個庫, 將單個表拆分成多個表,拆分規則策略, 後續說明
爲什麼要分庫分表?
白話
分表
前提：當單表數據量太大，會極大的影響sql的執行性能，這時sql會跑的很慢。根據實戰經驗來說，當單表到幾百萬的時候，性能就會有所下降
個人理解：白話來說就是把一個表的數據放到多個表中，查就查一個表，可以按照id來分表控制每個表的數據量，比如單表固定在200W以內。
分庫
單庫而言，最大的併發可能就2000左右，但是一個健壯的單庫來說最好的併發保持在1000左右。單數據庫增大或者併發增加的時候，可以將一個庫的數據拆分到多個庫中。
分庫分表的前因
- 新需求時,如果需要更新表結構,提交執行DDL(數據定義語言)會鎖表,如果此時表數據量過大就會導致執行時間過長
- 表數據過大,DML(數據庫操作語言)性能下降,響應時間緩慢
- 單機性能極限,採用以一主多策略,讀寫分離, 寫的請求落在主節點上，讀的請求落在從庫上，但是如果從庫過多會導致主從延時比較長，寫入的數據不能立刻查到，這個需要看具體業務場景，是否需要強制查詢主庫。
分庫分表前後對比
|
|
分庫分表前 |
分庫分表後 |
|
併發情況 |
Mysql單機，支撐不了高併發 |
Mysql集羣，併發加倍 |
|
磁盤情況 |
磁盤容量幾乎撐滿 |
拆分多個表，磁盤使用率降低 |
|
SQL性能 |
數據量加大，SQL越來越慢 |
單表數據量少，SQL效率提升明顯 |
怎麼分?
拆分規則
水平拆分
就是把一個表的數據分到多個庫的多個表中，每個庫的表結構一樣，不過每個庫存放的數據不同。水平拆分的意思就是將數據均勻放到更多表裏，然後多個庫來抗高併發，還有就是用多個庫的存儲容量來擴容
垂直拆分
就是把一個很多字段的表拆分給多個表，或者多個庫上去。每個庫表結構都不一樣，每個庫表都包含部分字段。一般來說，會將很少訪問的字段放到一個表，數據庫有緩存，訪問頻率高的字段越少，可以緩存更多的行，性能更好，這個一般在表層面操作。
如何拆分
其實大家可能都遇到到，比如說把一個訂單大表拆開，訂單表、訂單支付表、訂單商品表。
按數據量
一種是按照range來分，每個庫一段連續的數據，比如按時間來，但比較少用，比如大量流量產生大量數據。
按字段
一種是按照某個字段hash均勻分散，這個較常用
一個分表字段（一般是業務的主鍵 比如訂單Id），然後水平拆分（分表字段取模分表總數），那麼怎麼選擇這個分表字段呢主要需要考以下幾點：
1.是否便於查詢，比如訂單表，我們也可以按照訂單Id，也可以按照用戶Id來分。但是有時候，我們希望分庫分表後能夠滿足兩個Id查詢，比如訂單Id和userId，希望同一個userId的所有訂單都落到同一張表中，這樣就可以採用組合方的式生成分表字段訂單Id（全局自增主鍵+userId後四位），這種組合方式生成訂單Id做分表字段，即可用滿足訂單Id查詢又可以滿足用戶Id查詢。
2.數據分配是否相對均勻，不會出現數據的傾斜問題，如果選擇分表字段不是很合適就會導致一些表的數據比較多，而一些表的數據比較少，應當避免這種現象。
其他(組合拆分)
分庫分表後問題如何處理?
面臨問題
- 跨節點分頁、排序、函數問題
- 跨節點關聯查詢 join 問題
- 事務一致性問題
- 全局主鍵避重問題
- 數據遷移、擴容問題
事務處理
誇庫的事務不可用，原本的一個事務都是在同一庫的（事務是基於連接的），分庫後原本事務可能需要分到了不同的庫，這樣誇庫的事務就會不可用。
採用分庫分表中間件 – 處理事務
查詢處理
非分表字段來查詢的需求，這種情況下直接查詢的性能非常低，需要掃描全表，這種情況可以通過將數據導入到ElasticSearch（搜索引擎）來解決，通過搜索引擎來滿足查詢非分表字段，也可以建立一個route表這個表想到於二級索引（路由表主要存儲非分表字段到分表字段映射關係）。
目前常用分庫分表中間件
sharding-jdbc
噹噹開源，屬於client層，SQL語法支持比較多，支持分庫分表、讀寫分離、分佈式id生成、柔性事務（最大努力送達型事務、TCC事務），一直在維護，社區也比較活躍
參考使用sharding-jdbc網址: https://www.jianshu.com/p/e6385f802821
Mycat
基於proxy層方案，屬於目前非常火且不斷更新的數據庫中間件，支持功能也非常完善
區別和選擇
sharding-jdbc這種client層優點是不用部署，運維成本低，不需要代理層的二次轉發請求，性能很高，但是一旦升級，需要各個系統都重新升級版本在發佈，各個系統都需要耦合sharding-jdbc的依賴。
mycat這種proxy層的方案缺點就是自己運維一套中間件，運維成本高，但是好處在於對於各個項目透明，如果升級都是在中間件那裏搞定就可以了。
通常來說，小公司小項目建議使用sharding-jdbc，維護成本低，而大公司使用mycat這種proxy方案，大公司系統和項目多，有專人維護。
轉載至鏈接:https://my.oschina.net/java1314/blog/3036938。