1、面試題
爲什麼要分庫分表（設計高併發系統的時候，數據庫層面該如何設計）？用過哪些分庫分表中間件？不同的分庫分表中間件都有什麼優點和缺點？你們具體是如何對數據庫如何進行垂直拆分或水平拆分的？
2、面試官心理分析
其實這塊肯定是扯到高併發了，因爲分庫分表一定是爲了支撐高併發、數據量大兩個問題的。
而且現在說實話，尤其是互聯網類的公司面試，基本上都會來這麼一下，分庫分表如此普遍的技術問題，不問實在是不行，而如果你不知道那也實在是說不過去！
3、面試題剖析
（1）爲什麼要分庫分表？（設計高併發系統的時候，數據庫層面該如何設計？）
說白了，分庫分表是兩回事兒，大家可別搞混了，可能是光分庫不分表，也可能是光分表不分庫，都有可能。我先給大家拋出來一個場景。
假如我們現在是一個小創業公司（或者是一個BAT公司剛興起的一個新部門），現在註冊用戶就20萬，每天活躍用戶就1萬，每天單表數據量就1000，然後高峯期每秒鐘併發請求最多就10。。。天，就這種系統，隨便找一個有幾年工作經驗的，然後帶幾個剛培訓出來的，隨便乾乾都可以。如圖：
結果沒想到我們運氣居然這麼好，碰上個CEO帶着我們走上了康莊大道，業務發展迅猛，過了幾個月，註冊用戶數達到了2000萬！每天活躍用戶數100萬！每天單表數據量10萬條！高峯期每秒最大請求達到1000！
同時公司還順帶着融資了兩輪，緊張了幾個億人民幣啊！公司估值達到了驚人的幾億美金！這是小獨角獸的節奏！
好吧，現在大家感覺壓力已經有點大了，爲啥呢？因爲每天多10萬條數據，一個月就多300萬條數據，現在咱們單表已經幾百萬數據了，馬上就破千萬了。但是勉強還能撐着。高峯期請求現在是1000，咱們線上部署了幾臺機器，負載均衡搞了一下，數據庫撐1000 QPS也還湊合。如圖：
但是大家現在開始感覺有點擔心了，接下來咋整呢。。。。。。
再接下來幾個月，我的天，CEO太牛逼了，公司用戶數已經達到1億，公司繼續融資幾十億人民幣啊！公司估值達到了驚人的幾十億美金，成爲了國內今年最牛逼的明星創業公司！天，我們太幸運了。
但是我們同時也是不幸的，因爲此時每天活躍用戶數上千萬，每天單表新增數據多達50萬，目前一個表總數據量都已經達到了兩三千萬了！扛不住啊！數據庫磁盤容量不斷消耗掉！高峯期並發達到驚人的5000~8000！別開玩笑了，哥。我跟你保證，你的系統支撐不到現在，已經掛掉了！
好吧，所以看到你這裏你差不多就理解分庫分表是怎麼回事兒了，實際上這是跟着你的公司業務發展走的，你公司業務發展越好，用戶就越多，數據量越大，請求量越大，那你單個數據庫一定扛不住。
比如你單表都幾千萬數據了，你確定你能抗住麼？絕對不行，單表數據量太大，會極大影響你的sql執行的性能，到了後面你的sql可能就跑的很慢了。一般來說，就以我的經驗來看，單表到幾百萬的時候，性能就會相對差一些了，你就得分表了。
分表是啥意思？就是把一個表的數據放到多個表中，然後查詢的時候你就查一個表。
比如按照用戶id來分表，將一個用戶的數據就放在一個表中。然後操作的時候你對一個用戶就操作那個表就好了。這樣可以控制每個表的數據量在可控的範圍內，比如每個表就固定在200萬以內。如圖：
分庫是啥意思？就是你一個庫一般我們經驗而言，最多支撐到併發2000，一定要擴容了，而且一個健康的單庫併發值你最好保持在每秒1000左右，不要太大。那麼你可以將一個庫的數據拆分到多個庫中，訪問的時候就訪問一個庫好了。
這就是所謂的分庫分表，爲啥要分庫分表？你明白了吧
（2）用過哪些分庫分表中間件？不同的分庫分表中間件都有什麼優點和缺點？
這個其實就是看看你瞭解哪些分庫分表的中間件，各個中間件的優缺點是啥？然後你用過哪些分庫分表的中間件。
比較常見的包括：cobar、TDDL、atlas、sharding-jdbc、mycat
cobar：阿里b2b團隊開發和開源的，屬於proxy層方案。早些年還可以用，但是最近幾年都沒更新了，基本沒啥人用，差不多算是被拋棄的狀態吧。而且不支持讀寫分離、存儲過程、跨庫join和分頁等操作。
TDDL：淘寶團隊開發的，屬於client層方案。不支持join、多表查詢等語法，就是基本的crud語法是ok，但是支持讀寫分離。目前使用的也不多，因爲還依賴淘寶的diamond配置管理系統。
atlas：360開源的，屬於proxy層方案，以前是有一些公司在用的，但是確實有一個很大的問題就是社區最新的維護都在5年前了。所以，現在用的公司基本也很少了。
sharding-jdbc：噹噹開源的，屬於client層方案。確實之前用的還比較多一些，因爲SQL語法支持也比較多，沒有太多限制，而且目前推出到了2.0版本，支持分庫分表、讀寫分離、分佈式id生成、柔性事務（最大努力送達型事務、TCC事務）。
而且確實之前使用的公司會比較多一些（這個在官網有登記使用的公司，可以看到從2017年一直到現在，是不少公司在用的），目前社區也還一直在開發和維護，還算是比較活躍，個人認爲算是一個現在也可以選擇的方案。
mycat：基於cobar改造的，屬於proxy層方案，支持的功能非常完善，而且目前應該是非常火的而且不斷流行的數據庫中間件，社區很活躍，也有一些公司開始在用了。但是確實相比於sharding jdbc來說，年輕一些，經歷的錘鍊少一些。
所以綜上所述，現在其實建議考量的，就是sharding-jdbc和mycat，這兩個都可以去考慮使用。
sharding-jdbc這種client層方案的優點在於不用部署，運維成本低，不需要代理層的二次轉發請求，性能很高，但是如果遇到升級啥的需要各個系統都重新升級版本再發布，各個系統都需要耦合sharding-jdbc的依賴；
mycat這種proxy層方案的缺點在於需要部署，自己及運維一套中間件，運維成本高，但是好處在於對於各個項目是透明的，如果遇到升級之類的都是自己中間件那裏搞就行了。
通常來說，這兩個方案其實都可以選用，但是我個人建議中小型公司選用sharding-jdbc，client層方案輕便，而且維護成本低，不需要額外增派人手，而且中小型公司系統複雜度會低一些，項目也沒那麼多；
但是中大型公司最好還是選用mycat這類proxy層方案，因爲可能大公司系統和項目非常多，團隊很大，人員充足，那麼最好是專門弄個人來研究和維護mycat，然後大量項目直接透明使用即可。
我們，數據庫中間件都是自研的，也用過proxy層，後來也用過client層
（3）你們具體是如何對數據庫如何進行垂直拆分或水平拆分的？
水平拆分的意思，就是把一個表的數據給弄到多個庫的多個表裏去，但是每個庫的表結構都一樣，只不過每個庫表放的數據是不同的，所有庫表的數據加起來就是全部數據。
水平拆分的意義，就是將數據均勻放更多的庫裏，然後用多個庫來抗更高的併發，還有就是用多個庫的存儲容量來進行擴容。
垂直拆分的意思，就是把一個有很多字段的表給拆分成多個表，或者是多個庫上去。每個庫表的結構都不一樣，每個庫表都包含部分字段。
一般來說，會將較少的訪問頻率很高的字段放到一個表裏去，然後將較多的訪問頻率很低的字段放到另外一個表裏去。因爲數據庫是有緩存的，你訪問頻率高的行字段越少，就可以在緩存裏緩存更多的行，性能就越好。這個一般在表層面做的較多一些。
這個其實挺常見的，不一定我說，大家很多同學可能自己都做過，把一個大表拆開，訂單表、訂單支付表、訂單商品表。
還有表層面的拆分，就是分表，將一個表變成N個表，就是讓每個表的數據量控制在一定範圍內，保證SQL的性能。否則單表數據量越大，SQL性能就越差。一般是200萬行左右，不要太多，但是也得看具體你怎麼操作，也可能是500萬，或者是100萬。你的SQL越複雜，就最好讓單錶行數越少。
好了，無論是分庫了還是分表了，上面說的那些數據庫中間件都是可以支持的。就是基本上那些中間件可以做到你分庫分表之後，中間件可以根據你指定的某個字段值，比如說userid，自動路由到對應的庫上去，然後再自動路由到對應的表裏去。
你就得考慮一下，你的項目裏該如何分庫分表？一般來說，垂直拆分，你可以在表層面來做，對一些字段特別多的表做一下拆分；水平拆分，你可以說是併發承載不了，或者是數據量太大，容量承載不了，你給拆了，按什麼字段來拆，你自己想好；分表，你考慮一下，你如果哪怕是拆到每個庫裏去，併發和容量都ok了，但是每個庫的表還是太大了，那麼你就分表，將這個表分開，保證每個表的數據量並不是很大。
而且這兒還有兩種分庫分表的方式，一種是按照range來分，就是每個庫一段連續的數據，這個一般是按比如時間範圍來的，但是這種一般較少用，因爲很容易產生熱點問題，大量的流量都打在最新的數據上了；或者是按照某個字段hash一下均勻分散，這個較爲常用。
range來分，好處在於說，後面擴容的時候，就很容易，因爲你只要預備好，給每個月都準備一個庫就可以了，到了一個新的月份的時候，自然而然，就會寫新的庫了；缺點，但是大部分的請求，都是訪問最新的數據。實際生產用range，要看場景，你的用戶不是僅僅訪問最新的數據，而是均勻的訪問現在的數據以及歷史的數據，如圖：
hash分法，好處在於說，可以平均分配沒給庫的數據量和請求壓力；壞處在於說擴容起來比較麻煩，會有一個數據遷移的這麼一個過程，如圖：
覺得文章不錯就給小老弟點個關注吧，更多內容陸續奉上。
最後，分享一份面試寶典《Java核心知識點整理.pdf》，覆蓋了JVM、鎖、高併發、反射、Spring原理、微服務、Zookeeper、數據庫、數據結構等等。加入我的個人粉絲羣（Java架構技術棧：644872653）獲取免費領取方式。