分庫分表是高併發高可用系統的乙個重要的點，網際網路公司面試常常會問道。
為什麼要分庫分表（設計高併發系統的時候，資料庫層面應該如何設計）？
首先要清楚，分庫和分表是兩回事，是兩個獨立的概念。分庫和分表都是為了防止資料庫服務因為同一時間的訪問量（增刪查改）過大導致宕機而設計的一種應對策略。
為什麼要分庫
按一般的經驗來說，乙個單庫最多支援併發量到2000，且最好保持在1000。如果有20000併發量的需求，這時就需要擴容了，可以將乙個庫的資料拆分到多個庫中，訪問的時候根據一定條件訪問單庫，緩解單庫的效能壓力。
為什麼要分表
分表也是一樣的，如果單錶的資料量太大，就會影響sql語句的執行效能。分表就是按照一定的策略將單錶的資料拆分到多個表中，查詢的時候也按照一定的策略去查詢對應的表，這樣就將一次查詢的資料範圍縮小了。比如按照使用者id來分表，將乙個使用者的資料就放在乙個表中，crud先通過使用者id找到那個表在進行操作就可以了。這樣就把每個表的資料量控制在一定範圍內，提公升sql語句的執行效能。
用過哪些分庫分表的中介軟體？不同的分庫分表中介軟體都有什麼優點和缺點？
分庫分表常見的中介軟體有：cobar、tddl、atlas、sharding-jdbc和mycat等。
cobar
cobar是阿里的b2b團隊開發和開源的，屬於proxy層方案，介於應用伺服器和資料庫伺服器之間。應用程式通過jdbc驅動訪問cobar集群，cobar根據sql和分庫規則對sql做分解，然後分發到mysql集群不同的資料庫例項上執行。cobar並不支援讀寫分離、儲存過程、跨庫join和分頁等操作。早些年還可以用，但是最近幾年都沒更新了，基本沒啥人用，算是淘汰了。
tddl
tddl是**團隊開發的，屬於client層方案。支援基本的crud語法和讀寫分離，但是並不支援join、多表查詢等語法。目前使用的也不多，因為使用還需要依賴**的diamond配置管理系統。
atlas
atlas是360開源的，屬於proxy層方案。以前是有一些公司再用的，但是社群最新的維護都在5年前了，現在用的公司也基本沒有了。
sharding-jdbc
sharding-jdbc是噹噹開源的，屬於client層方案。這個中介軟體對sql語法的支援比較多，沒有太多限制。2.0版本也開始支援分庫分表、讀寫分離、分布式id生成、柔性事務（最大努力送達型事務、tcc事務）。目前社群也還一直在開發和維護，算是比較活躍，是乙個現在也可以選擇的方案。
mycat
mycat是基於cobar改造的，屬於proxy層方案。其支援的功能十分完善，是目前非常火的乙個資料庫中介軟體。社群很活躍，不斷在更新。相比於sharding-jdbc來說，年輕一些，經歷的錘煉也少一些。
總結綜上所述，現在建議考量使用的就是sharding-jdbc和mycat。
sharding-jdbc這種client層的優點在於不用部署，因此運維成本也就比較低。同時因為不需要**層的二次**請求，效能很高。但是如果遇到公升級的話，需要各個系統都重新公升級版本再發布，因為各個系統都需要耦合sharding-jdbc的依賴。
mycat這種proxy方案的缺點在於需要部署，因此運維成本也就比較高。但是優點在於其對於各個專案是透明（解耦）的，如果要公升級的話只需要在中介軟體處理就行了。
通常來說，這兩個方案都是可以選用的。但是建議中小型公司選用sharding-jdbc比較好，因為client層方案輕便，維護成本低；建議中大型公司選用mycat比較好，因為proxy層方案可以應對多個系統和專案大量使用，雖然維護成本相對來說會較高，但是中大型公司還缺這點人力嗎。
具體如何對資料庫進行垂直拆分或水平拆分？
水平拆分的概念
水平拆分的意思，就是把乙個表的資料拆分到多個庫的多個表裡面去。這裡面的每個庫的表結構都是一樣的，只不過是表中存放的資料不一樣，每個庫表的資料彙總起來就是全部資料。水平拆分的意義在於將資料均勻地存放在各個庫表裡，依靠多個庫來槓更高的併發，而且還能借助多個庫的儲存容量來進行擴容。
垂直拆分的概念
垂直拆分的意思，就是把乙個有很多欄位的表給拆分成多個表或者多個庫上面去，每個庫表的結構都不一樣，每個庫表都包含部分字段。一般來說，會將較少的訪問頻率很高的字段放到乙個表裡面去，然後將較多的訪問頻率很低的字段放到另外乙個表裡面去。因為資料庫是有快取的，你訪問頻率高的行欄位越少，就可以在快取裡面快取更多的行，效能也就越好。這個一般在表層面做的較多一些。
水平拆分和垂直拆分的場景
所謂表層面的拆分，就是分表。具體就是將乙個表拆分為n個表，讓每個表的資料量控制在一定的範圍內，保證sql的效能。否則，單錶的資料量越大，sql的效能也就越差，一般是200萬行左右，不要太多。如果你的sql越複雜，就盡量讓單錶的行數越少。
無論是分庫還是分表，主流的資料庫中介軟體都是可以支援的。這些中介軟體可以在你分庫分表之後，根據指定的某個字段值自動路由到對應的庫和對應的表上面。這時就只要考慮專案如何分庫分表就行了。一般來說，垂直拆分，可以在表層面做，即對一些字段特別多的表做一下拆分；水平拆分的話，可能是因為併發承載不了或容量承載不了，也就可以按某個欄位去分布到不同的庫表裡面去。
分庫分表的兩個方案
這裡說一下兩種分庫分表的方案和它們的優缺點。
1.按照range來分。比如說按照時間範圍來分庫分表，每個庫表中存放的都是連續時間範圍的資料。但是這種方式一般很少用，因為很容易會產生熱點問題，大量的流量都打在最新的資料上了。這種方案的優點在於擴容的時候非常簡單，比如只要預備好每個月都準備乙個庫就可以了，到了下乙個新的月份自動將資料寫入新的庫。缺點則是，如果大部分請求都是訪問最新的資料，那麼在這裡，分庫分表的設計目的就只是簡單的擴容，而不是為了應對高併發了。
2.按照hash分發。按照某個欄位的hash值均勻分散，這個較為常用。優點在於可以平均分配每個庫表的資料量和請求壓力；缺點在於擴容比較麻煩，因為會存在乙個資料遷移的過程，即之前的資料需要重新計算hash值並重新分配到不同的庫表中。
"乙個人最幸福的時刻，就是找對了人。ta會包容你的不足，並愛著你的一切。"
面試題 為什麼要分庫分表
為什麼要分表分庫 設計高併發系統的時候，資料庫層面該如何設計 使用過哪些分表分庫中介軟體？不同的分表分庫中介軟體都有什麼優點和缺點？你們是如何對具體的資料庫進行垂直拆分和水平拆分的？其實這一塊內容主要就是針對高併發的，因為分庫分表主要解決的問題就是支撐高並 資料量大兩個問題。而且現在如果是去網際網路...
幾個面試題
1 公司裡面有1001個員工，現在要在公司裡面找到最好的羽毛球選手，也就是第一名，每個人都必須參賽，問至少要比賽多少次才能夠找到最好的羽毛球員工 2 現在有100個燈泡，每個燈泡都是關著的，第一趟把所有的燈泡燈泡開啟，第二趟把偶數字的燈泡制反 也就是開了的關掉，關了的開啟 第三趟讓第3,6,9.的燈...
幾個面試題
面試的時候被問到的幾個c 的題目 1.空類的大小 答 0 2.空類自帶幾個函式 答 1.建構函式 2.析構函式 3.拷貝構造 4.賦值操作符 5.取位址操作符 6.const取位址 3.父類的析構函式為什麼要是虛函式 父類指標指向乙個子類物件，析構這個父類指標時，如析構函式不是虛函式，將不會析構子物...