題目：高并發情況下，數據庫該如何設計？

JAVA高級面試題：為什么要分庫分表（ 設計高并發系統的時候 ， 數據庫層面該如何設計 ） ？ 用過哪些分庫分表中間件 ？ 不同的分庫分表中間件都有什么優點和缺點？ 你們具體是如何對數據庫 如何進行垂直拆分或水平拆分的？

題目來源：Java高級架構面試知識點整理--MySQL分庫分表問題（附解析，如下圖）

Java高級面試：MySQL分庫分表問題

Java高級架構面試知識點整理：包含消息隊列、redis緩存、MySQL分庫分表、讀寫分離、設計高并發系統、分布式系統、高可用架構、SpringCloud微服務架構 等8大類近200頁的內容，從面試官心理分享 到 面試題剖析，一步一步扣題深入，通俗易懂，是不可多得的干貨！

如需原件學習，可私信@追逐仰望星空口令【高級】分享！

面試官心理分析

其實這塊肯定是扯到高并發了，因為分庫分表一定是為了支撐高并發、數據量大兩個問題的。而且現在說實話，尤其是互聯網類的公司面試，基本上都會來這么一下，分庫分表如此普遍的技術問題，不問實在是不行，而如果你不知道那也實在是說不過去！

面試題剖析

為什么要分庫分表？（設計高并發系統的時候，數據庫層面該如何設計？）

說白了，分庫分表是兩回事兒，大家可別搞混了，可能是光分庫不分表，也可能是光分表不分庫，都有可能。我先給大家拋出來一個場景：

假如我們現在是一個小創業公司(或者是一個BAT公司剛興起的一個新部門)，現在注冊用戶就20萬，每天活躍用戶就1萬，每天單表數據量就1000，然后高峰期每秒鐘并發請求最多就10。天，就這種系統，隨便找一個有幾年工作經驗的，然后帶幾個剛培訓出來的，隨便干什么都可以。

結果沒想到我們運氣居然這么好，碰上個CEO帶著我們走上了康莊大道，業務發展迅猛，過了幾個月，注冊用戶數達到了2000萬！每天活躍用戶數100萬！每天單表數據量10萬條!高峰期每秒最大請求達到1000！同時公司還順帶著融資了兩輪，進賬了幾個億人民幣啊!公司估值達到了驚人的幾億美金！這是小獨角獸的節奏！

好吧，沒事，現在大家感覺壓力已經有點大了，為啥呢?因為每天多10萬條數據，一個月就多300萬條數據，現在咱們單表已經幾百萬數據了，馬上就破千萬了。但是勉強還能撐著。高峰期請求現在是1000，咱們線上部署了幾臺機器，負載均衡搞了一下，數據庫撐1000QPS也還湊合。但是大家現在開始感覺有點擔心了，接下來咋整呢..... .

在接下來幾個月，我的天，CEO 太牛逼了，公司用戶數已經達到1億，公司繼續融資幾十億人民幣啊！公司估值達到了驚人的幾十億美金，成為了國內今年最牛逼的明星創業公司!天，我們太幸運了。

但是我們同時也是不幸的，因為此時每天活躍用戶數上千萬，每天單表新增數據多達 50萬，目前一個表總數據量都已經達到了兩三千萬了!扛不住啊!數據庫磁盤容量不斷消耗掉!高峰期并發達到驚人的

5000~8000!別開玩笑了，哥。我跟你保證，你的系統支撐不到現在，已經掛掉了！

好吧，所以你看到這里差不多就理解分庫分表是怎么回事兒了，實際上這是跟著你的公司業務發展走的，你公司業務發展越好，用戶就越多，數據量越大，請求量越大，那你單個數據庫一定扛不住。

分表

比如你單表都幾千萬數據了，你確定你能扛住么？絕對不行，單表數據量太大，會極大影響你的 sql 執行的性能，到了后面你的 sql可能就跑得很慢了。一般來說，就以我的經驗來看，單表到幾百萬的時候，性能就會相對差一些了，你就得分表了。

分表是啥意思？就是把一個表的數據放到多個表中，然后查詢的時候再查一個表。比如按照用戶id來分表，將一個用戶的數據就放在一個表中。然后操作的時候你對一個用戶就操作那個表就好了。這樣可以控制每個表的數據量在可控的范圍內，比如每個表就固定在 200萬以內。

分庫

分庫是啥意思？就是你一個庫一般我們經驗而言，最多支撐到并發2000，一定要擴容了，而且一個健康的單庫并發值你最好保持在每秒1000 左右，不要太大。那么你可以將一個庫的數據拆分到多個庫中，訪問的時候就訪問一個庫好了。

這就是所謂的分庫分表，為啥要分庫分表？你明白了吧。

你們具體是如何對數據庫如何進行垂直拆分或水平拆分的？

水平拆分的意思，就是把一個表的數據給弄到多個庫的多個表里去，但是每個庫的表結構都一樣，只不過每個庫表放的數據是不同的，所有庫表的數據加起來就是全部數據。水平拆分的意義，就是將數據均勻放在更多的庫里，然后用多個庫來扛更高的并發，還有就是用多個庫的存儲容量來進行擴容。

垂直拆分的意思，就是把一個有很多字段的表給拆分成多個表，或者是多個庫上去。每個庫表的結構都不一樣，每個庫表都包含部分字段。一般來說，會將較少的訪問頻率很高的字段放到一個表里去，然后將較多的訪問頻率很低的字段放到另外一個表里去。因為數據庫是有緩存的，你訪問頻率高的行字段越少，就可以在緩存里緩存更多的行，性能就越好。這個一般在表層面上做得較多一些。

還有表層面的拆分，就是分表，將一個表變成N個表，就是讓每個表的數據量控制在一定范圍內，保證SQL 的性能。否則單表數據量越大，SQL性能就越差。一般是200萬行左右，不要太多，但是也得看具體你怎么操作，也可能是500萬，或者是100萬。你的SQL越復雜，就最好讓單表行數越少。

涉及高并發系統，我該怎么辦？

如果不想只是單純地做個底層CRUD的搬磚程序員，那么對于高并發系統設計這一類的問題，你必須得掌握！不用慌，小編整理了46問，貫穿整個高并發系統設計的問題，涉及：基礎、數據庫、緩存、消息隊列、分布式、維護、實戰操練等7個部分的內容（并將每一問的答案解析整理完整）。

1. 為什么要學習高并發系統設計？
2. 高并發系統：它的通用設計方法是什么
3. 架構分層：我們為什么一定要這么做
4. 系統設計目標（一）：如何提升系統性能
5. 系統設計目標（二）：系統怎樣做到高可用
6. 系統設計目標（三）：如何讓系統易于擴展
7. 面試現場第一期：當問到組件實現原理時，面試官是在刁難你嗎？
8. 池化技術：如何減少頻繁創建數據庫連接的性能損耗？
9. 數據庫優化方案（一）：查詢請求增加時，如何做主從分離
10. 數據庫優化方案（二）：寫入數據量增加時，如何實現分庫分表
11. 發號器：如何保證分庫分表后ID的全局唯─性？
12. NoSQL：在高并發場景下，數據庫和 NoSQL 如何做到互補？
13. 緩存：數據庫成為瓶頸后，動態數據的查詢要如何加速？
14. 緩存的使用姿勢（一）：如何選擇緩存的讀寫策略？
15. 緩存的使用姿勢（二）：緩存如何做到高可用？
16. 緩存的使用姿勢（三）：緩存穿透了怎么辦？
17. CDN：靜態資源如何加速？
18. 數據的遷移應該如何做？
19. 消息隊列：秒殺時如何處理每秒上萬次的下單請求？
20. 消息投遞：如何保證消息僅僅被消費一次？
21. 消息隊列：如何降低消息隊列系統中消息的延遲？
22. 面試現場第二期：當問到項目經驗時，面試官究竟想要了解什么
23. 從“心”出發，我還有無數個可能
24. 高并發系統設計期中測試題目解析
25. 系統架構：每秒1萬次請求的系統要做服務化拆分嗎？
26. 微服務架構：微服務化后系統架構要如何改造？
27. RPC框架：10萬 Q P S 下如何實現毫秒級的服務調用？
28. 注冊中心：分布式系統如何尋址？
29. 分布式Trace :橫跨幾十個分布式組件的慢請求要如何排查？
30. 負載均衡：怎樣提升系統的橫向擴展能力？
31. A P I 網關：系統的門面要如何做呢？
32. 多機房部署：跨地域的分布式系統如何做？
33. Service Mesh：如何屏蔽服務化系統的服務治理細節？
34. 給系統加上眼睛：服務端監控要怎么做？
35. 應用性能管理：用戶的使用體驗應該如何監控？
36. 壓力測試：怎樣設計全鏈路壓力測試平臺？
37. 配置管理：成千上萬的配置項要如何管理？
38. 降級熔斷：如何屏蔽非核心系統故障的影響？
39. 流量控制：高并發系統中我們如何操縱流量？
40. 面試現場第三期：你要如何準備—場技術面試呢？
41. 計數系統設計（一）：面對海量數據的計數器要如何做
42. 計數系統設計（二）：50萬 Q PS下如何設計未讀數系統
43. 信息流設計（一）：通用信息流系統的推理模式要如何做
44. 信息流設計（二）：通用信息流系統的拉模式要如何做
45. 高并發下如何發現和排查問題？
46. 我們如何準備抵抗流量峰值？

答案解析原件（如下圖，內容過多近400頁的高并發系統設計文檔，無法一一將答案上傳，但皆可分享原件給感興趣想學習的你，私信@追逐仰望星空口令【高級】即可）

高并發系統設計

此外，怎么肝下MySQL？

想肝MySQL說難也還行吧，不說別的，我準備了167道超高頻的MySQL面試問題（附解析，包含從基礎-索引-鎖-日志-調優等內容），想做Java高級程序員乃至Java架構師，想拿阿里P7-P8的offer，先將下面這些內容裝進腦子里吧！

MySQL

答案解析原件（如下圖，內容過多64頁的167道超高頻的MySQL面試文檔，無法一一將答案上傳，但已整理如下的文檔）

MySQL

為了邁向高級程序員，那么這份 MySQL高級知識筆記手寫文檔（12章節內容） 同樣不可錯過！！

1. MySql重要性質
2. MySQL安裝
3. Mysql權限
4. MySql數據類型
5. Mysql架構
6. 存儲引擎
7. 鎖
8. 事務
9. 業務設計
10. 慢查詢
11. 索引與執行計劃
12. SQL優化

面試突擊MySQL，哪怕涉及高并發系統設計的內容，千萬不要慌張！沉著！冷靜！