分庫分表介紹：
分庫分表的目的是為了系統高并發、高可用。分庫和年發表是兩回事，兩個概念，都是為了防止數據庫服務因為同一時間內訪問量過大導致宕機而設計的一種應對策略。
一、為什么要分庫：
參考：
https://www.cnblogs.com/yanggb/p/11214339.html
一般經驗來說，單庫支持的最大并發量到2000，最好的運行是1000。如果更高的并發量需求，就需要考慮擴容，將一個庫的數據拆分到多個庫中，訪問的時候根據一定條件訪問單庫，緩解單庫的性能壓力。
二、為什么要分表：
分表也是考慮到性能，單表數據量太大的時候sql的執行性能就降低。分表就是按照一定的策略將單表的數據拆分到多表中，查詢也按照一定的策略去查詢，這樣查詢的數據范圍就縮小了，比如按照用戶id來分表，通過id確定哪個表，把表的數據量控制在一定范圍內，提升sql語句執行性能。
選型介紹：
參考:
https://www.it610.com/article/1281542839301324800.htm
https://blog.csdn.net/xuheng8600/article/details/80336094
一、三個問題：
1.事務一致性:比如更新10張表，最后一張失敗，怎樣保證事務
2.字典表問題：字典表維護一個庫影響效率，多個庫存儲出現事務一致性、冗余問題
3.分頁查詢問題：如果使用mycat，進行分頁的時候會面臨數據量大的問題
二、中間件對比：
|
中間件 |
說明 |
備注 |
|
Atlas |
不能實現分布式分表，所有的子表必須在同一臺DB的同一個database里且所有的子表必須事先建好，Atlas沒有自動建表的功能。 |
|
|
Cobar |
必須將拆分后的表分別放入不同的庫來實現分布式。 |
擴展性的問題放棄 |
|
TDDL |
阿里，功能強大，過于復雜，部分開源。需要評估使用情況，防止過剩。 |
阿里系 |
|
Mycat |
國內開源，從入門到放 |
名氣大，已經到頭了 |
|
heisenberg |
百度開源，相對簡單，易于管理。 |
現在不維護了 |
|
Oceanus |
功能強大，開源，簡化開發和配置成功。但產品還不成熟。 |
|
|
vitess |
google產品，集群基于ZooKeeper管理，通過RPC方式進行數據處理，可支撐高流量，它還添加了一個連接池，具有基于行的高速緩存，重寫SQL查詢，更安全 |
|
|
OneProxy |
中國廠商產品，穩定性待確認。 |
|
|
Sharding-JDBC |
當當最新開源，jdbc層面操作 |
靠譜 |
sharding-jdbc這種client層的有點在于不用部署，運維成本就比較低。同時不需要代理層二次轉發請求，性能高。缺點是：遇到升級的話，各個系統都重新升級版本再發布，因為各個系統都需要耦合sharding-jdbc依賴。
mycat這種proxy方案缺點在于需要部署，因此運維成本增加。但是優點是各個項目是解耦的，升級的話就是處理中間件就行。
三、概念介紹：
|
概念 |
介紹 |
總結 |
|
水平拆分 |
水平拆分的意思，就是把一個表的數據拆分到多個庫的多個表里面去。這里面的每個庫的表結構都是一樣的，只不過是表中存放的數據不一樣，每個庫表的數據匯總起來就是全部數據。水平拆分的意義在于將數據均勻地存放在各個庫表里，依靠多個庫來杠更高的并發，而且還能借助多個庫的存儲容量來進行擴容 |
表結構一樣、擴容、高并發 |
|
垂直拆分 |
垂直拆分的意思，就是把一個有很多字段的表給拆分成多個表或者多個庫上面去，每個庫表的結構都不一樣，每個庫表都包含部分字段。一般來說，會將較少的訪問頻率很高的字段放到一個表里面去，然后將較多的訪問頻率很低的字段放到另外一個表里面去。因為數據庫是有緩存的，你訪問頻率高的行字段越少，就可以在緩存里面緩存更多的行，性能也就越好。這個一般在表層面做的較多一些。 |
拆分字段、利用緩存提升性能 |
四、兩種方案：
|
方案 |
優點 |
缺點 |
|
按照range區分 |
比較常用的是按照時間劃分，擴容簡單，下個月自動寫入庫 |
熱點數據會請求到同一個表，起不到高并發 |
|
按照hash分發 |
按照字段hash值均勻分布，平均分配每個庫表的數據量和請求壓力 |
擴容麻煩，數據遷移需要重新計算hash值并重新分配 |
