一.為什麼要分庫分表？
分庫分表是為了支援高并發，資料量大兩個問題的。
1.分表
單表資料量太大，會極大影響sql執行的性能，到了後面sql可能就跑的很慢了。
分表就是把一個表的資料放到多個表中，然後查詢的時候就查一個表。比如按照使用者id分表，将一個使用者的資料就放在一個表中，然後操作的時候對一個使用者就操作那個表就好了。每張表資料在200萬以内。
分表主要解決資料量大的問題。
2.分庫
分庫就是一個庫依經驗而言，最多支撐到并發2000，一定要擴容了，而且一個健康的單庫并發值最好保持在每秒1000左右，不要太大。那麼可以将一個庫的資料拆分到多個庫中，通路的時候就通路一個庫就好了。
二.分庫分表中間件
1.Sharding-jdbc
當當開源的，屬于 client 層方案，目前已經更名為 ShardingSphere（後文所提到的 Sharding-jdbc，等同于 ShardingSphere）。确實之前用的還比較多一些，因為 SQL 文法支援也比較多，沒有太多限制，而且截至 2019.4，已經推出到了 4.0.0-RC1 版本，支援分庫分表、讀寫分離、分布式 id 生成、柔性事務（最大努力送達型事務、TCC 事務）。而且确實之前使用的公司會比較多一些（這個在官網有登記使用的公司，可以看到從 2017 年一直到現在，是有不少公司在用的），目前社群也還一直在開發和維護，還算是比較活躍，個人認為算是一個現在也可以選擇的方案。
2.Mycat
基于 Cobar 改造的，屬于 proxy 層方案，支援的功能非常完善，而且目前應該是非常火的而且不斷流行的資料庫中間件，社群很活躍，也有一些公司開始在用了。但是确實相比于 Sharding jdbc 來說，年輕一些，經曆的錘煉少一些。
優缺點：
Sharding-jdbc 這種 client 層方案的優點在于不用部署，運維成本低，不需要代理層的二次轉發請求，性能很高，但是如果遇到更新啥的需要各個系統都重新更新版本再釋出，各個系統都需要耦 合 Sharding-jdbc 的依賴；
Mycat 這種 proxy 層方案的缺點在于需要部署，自己運維一套中間件，運維成本高，但是好處在于對于各個項目是透明的，如果遇到更新之類的都是自己中間件那裡搞就行了。
三.資料庫如何進行垂直拆分或水準拆分？
1.水準拆分
把一張表的資料給弄到多個庫的多個表中，但是每個庫的表結構都一樣，隻不過每個庫表放的資料是不同的，所有庫表的資料加起來就是全部資料。水準拆分的意義，就是将資料均勻放更多的庫裡，然後用多個庫來抗更高的并發，還有就是用多個庫的存儲量來進行擴容。
2.垂直拆分
把一個有很多字段的表拆分成多個表，或者多個庫上去。每個庫表的結構都不一樣，每個庫表都包含部分字段。一般來說，會将較少的通路頻率很高的字段放到一個表裡去，然後将較多的通路頻率很低的字段放到另一個表裡去。因為資料庫是有緩存的，你通路頻率高的行字段越少，就可以在緩存裡緩存更多的行，性能就越好。
四.動态切換到分庫分表
1.停機遷移方案
先給你說一個最 low 的方案，就是很簡單，大家夥兒淩晨 12 點開始運維，網站或者 app 挂個公告，說 0 點到早上 6 點進行運維，無法通路。
接着到 0 點停機，系統停掉，沒有流量寫入了，此時老的單庫單表資料庫靜止了。然後你之前得寫好一個導數的一次性工具，此時直接跑起來，然後将單庫單表的資料嘩嘩嘩讀出來，寫到分庫分表裡面去。導數完了之後，就 ok 了，修改系統的資料庫連接配接配置啥的，包括可能代碼和 SQL 也許有修改，那你就用最新的代碼，然後直接啟動連到新的分庫分表上去。
2.雙寫遷移方案
簡單來說，就是線上上系統裡面，之前所有寫庫的地方，增删改操作，除了對老庫增删改，都加上對新庫的增删改，這就是所謂的雙寫，同時寫倆庫，老庫和新庫。
然後系統部署之後，新庫資料差太遠，用之前說的導數工具，跑起來讀老庫資料寫新庫，寫的時候要根據 gmt_modified 這類字段判斷這條資料最後修改的時間，除非是讀出來的資料在新庫裡沒有，或者是比新庫的資料新才會寫。簡單來說，就是不允許用老資料覆寫新資料。
導完一輪之後，有可能資料還是存在不一緻，那麼就程式自動做一輪校驗，比對新老庫每個表的每條資料，接着如果有不一樣的，就針對那些不一樣的，從老庫讀資料再次寫。反複循環，直到兩個庫每個表的資料都完全一緻為止。
接着當資料完全一緻了，就ok了，基于僅僅使用分庫分表的最新代碼，重新部署一次，不就僅僅基于分庫分表在操作了麼，還沒有幾個小時的停機時間，很穩。是以現在基本玩兒資料遷移之類的，都是這麼幹的。
風裡雨裡,善知教育等你!!
QQ:1763481971
或加交流群