為什麼要分表分庫（設計高併發系統的時候，資料庫層面該如何設計）？使用過哪些分表分庫中介軟體？不同的分表分庫中介軟體都有什麼優點和缺點？你們是如何對具體的資料庫進行垂直拆分和水平拆分的？
其實這一塊內容主要就是針對高併發的，因為分庫分表主要解決的問題就是支撐高並、資料量大兩個問題。而且現在如果是去網際網路公司面試的話，基本上都是會問一下的。
為什麼要分庫分表？（設計高併發系統的時候，資料庫層面該如何設計？）
說白了，分庫和分表是兩碼事，可能在實際專案中，只分庫不分表，也可能是只分表不分庫。分表和分庫對應的是不同的場景，也是為了解決不同的問題。
分表比如現在系統中的單錶資料量已經有上億條了，你的單錶資料量過大，會直接影響sql的執行效能，依照經驗，當單錶資料量過百萬的時候，就會逐漸出現效能問題，就需要考慮分表。
分表就意味著講資料拆分開來，進行資料分片，每一部都包含少量的資料，可以將
每個表的資料控制在一定的範圍內。
分庫分庫是什麼意思？根據生產經驗一台資料庫的併發量，大概撐的到2000左右，否則就可能出現崩潰問題。乙個健康的單庫併發量最好在1000左右，不要太大。可以將乙個庫的資料拆分到多個庫，訪問的時候只訪問乙個庫就行了。
-分表分庫前
分表分庫後
併發支撐情況
mysql單機部署，扛不住高併發
mysql從單機到多機，能承受的併發增加了多倍
磁碟使用情況
mysql的磁碟空間幾乎撐滿
拆分為多個庫，資料庫磁碟使用率大大降低
sql執行效能
單錶資料量太大，sql越跑越慢
單錶資料量減少，sql執行效率明顯提公升
用過哪些分庫分表中介軟體，不同的分庫分表中介軟體都有什麼優點和缺點？
這個其實就是技術選型的問題，知道各種的分庫分表中介軟體，以及對他們的長處短處做到心中有數。
比較常見的有：
cobar
阿里b2b團隊發開和開源的，屬於proxy層方案，就是介於應用伺服器和資料庫伺服器之間。應用程式通過jdbc驅動訪問cobar集群，cobar根據sql和分庫規則對sql做分解，然後分發到mysql集群不同的資料庫例項上執行。目前已經沒什麼維護了。
tddl
**團隊開發，屬於client層方案。支援基本的crud愈發和讀寫分離，但不支援join、多表查詢等語法。目前使用的也不多。
altas
360開源的，屬於proxy層方案，以前是有一些公司在用的，但是確實有乙個很大的問題就是社群最新的維護都在5年前了。所以現在用的公司比較少。
sharding-sphere
噹噹開源的，屬於client層方案，目前已經更名為shardingsphere。因為sql語法支援的比較多，而且沒有太多限制，使用的比較多。
mycat
基於cobar改造，屬於proxy層方案，支援的功能非常完善，而且目前應該是非常火的而且不斷流行的資料庫中介軟體，社群很活躍，也有一些公司開始在用了。但是相對於sharding-sphere來說要年輕一些，發現時間相對少一些。
總結其實業界主流的分庫分表中介軟體只有兩個sharding-sphere和mycat。
sharding-sphere：這中client層的方案的優點在於不用部署，運維成本低，不需要**層的二次**，效能很高，但是如果公升級什麼的，整個系統都需要重新發布，對sharding-sphere的耦合度比較高。
mycat：這種proxy層方案的缺點在於需要部署，自己運維一套中介軟體，運維成本高，但是好處在於對於各個專案都是透明的，如果遇到公升級之類的都是自己中介軟體那裡搞就行了。
通常來講，這兩種方案都是可行的。對於小公司來說，sharding-sphere比較合適，效能高，運維成本低，不需要額外的成本，而且中小型公司專案量和業務複雜度也沒有特別大。但是大公司最好還是選用proxy這種方案，因為大公司可能專案比較多，花點人力和物力來維護一套資料中介軟體，這樣對於專案來說就是透明的，還是非常值得的。
你們具體是如果對資料庫進行垂直拆分和水平拆分的？
水平拆分的意思，就是把乙個表的資料弄到多個表（庫）裡面去，每個表的資料結構都是一樣的，只不過資料量不同，所有的表加起來，就是全部的資料。水平拆分的意義，就是將資料均勻的分布在多個庫裡面，讓更多的庫來抗高併發，還有就是用多個庫的儲存量來進行擴容。
垂直拆分的意思，就是把乙個有很多欄位的表拆分成多個表，或者是多個庫上去。每個庫包含的是部分字段。一般來說，將訪問量比較高的字段放入乙個表中，將訪問量比較低的字段放入乙個表中。因為資料庫是有快取的，而快取是有限的資源，當行數越少的時候，效能就越好。
其實垂直拆分的情況，還是很常見的，將一張大表拆開，比如訂單表，訂單支付表，訂單商品表。
水平拆分是保證了單錶資料量不會太高，保證了sql執行的效能。無論是分庫還是分表，上面的中介軟體都是支援的。基本上上述中介軟體可以做到分庫分表之後，中介軟體可以根據你給定的某個值，然後自動路由到對應的庫上，然後再自動路由到對應的表裡。
你就得考慮一下，在專案中該如何做到分庫分表？一般來說，垂直拆分，你可以在表面層來做，對一些字段特別多的表可以做垂直拆分。水平拆分，可以說是併發承受不了，或者資料量太多了，可以做水平拆分。
而且這裡還有兩種分庫分表方式：
range來分，好處在於，擴容的時候很簡單，只需要準備好，比如按照時間間隔，每個月分乙個庫就可以了。缺點是可能出現熱點傾斜，大量的請求都訪問的是最新的庫。
hash來分，好處在於，可以平均分配每個庫的資料量和請求壓力；壞處在於擴容起來相對比較麻煩，會有乙個rehash所帶來的資料遷移問題。
為什麼要分庫分表
初學者在看到這個問題的時候，可能首先想到的是 mysql 一張表到底能存放多少條資料？根據 mysql 官方文件的介紹，mysql 理論上限是232 受限於32位軟體 條資料，然而實際操作中，往往還受限於下面兩條因素 myisamdatapointersize，mysql 的 myisamdatap...
mysql為什麼要分庫分表？
1 基本思想之什麼是分庫分表？從字面上簡單理解，就是把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存到多個表上。2 基本思想之為什麼要分庫分表？單錶運算元據量有最優值，mysql為1000萬左右 可以減輕資料庫的壓力，不用所有執行緒都查同乙個資料庫 資料庫中的資料量不一定...
我們為什麼要分庫分表
本文 當一張表的資料達到幾千萬時，查詢一次所花的時間會變長。這時候，如果有聯合查詢的話，可能會卡死在那兒，甚至把系統給拖垮。而分庫分表的目的就在於此 減小資料庫的負擔，提高資料庫的效率，縮短查詢時間。另外，因為分庫分表這種改造是可控的，底層還是基於rdbms，因此整個資料庫的運維體系以及相關基礎設施...