數據庫考點：為什麼要分庫分表？用過哪些分庫分表中間件？不同的分庫分表中間件都有什麼優點和缺點？如何對數據庫如何進行拆分？
01 為什麼要分庫分表？（設計高併發系統的時候，數據庫層面該如何設計？）
說白了，分庫分表是兩回事兒，大家可別搞混了，可能是光分庫不分表，也可能是光分表不分庫，都有可能。
（1）先給大家拋出來一個場景
假如我們現在是一個小創業公司（或者是一個 BAT 公司剛興起的一個新部門），現在註冊用戶就 20 萬，每天活躍用戶就 1 萬，每天單表數據量就 1000，然後高峰期每秒鐘併發請求最多就 10 個。我的天，就這種系統，隨便找一個有幾年工作經驗的，然後帶幾個剛培訓出來的，隨便乾乾都可以。
結果沒想到我們運氣居然這麼好，碰上個 CEO 帶著我們走上了康莊大道，業務發展迅猛，過了幾個月，註冊用戶數達到了 2000 萬！每天活躍用戶數 100 萬！每天單表數據量 10 萬條！高峰期每秒最大請求達到 1000！同時公司還順帶著融資了兩輪，進賬了幾個億人民幣啊！公司估值達到了驚人的幾億美金！這是小獨角獸的節奏！
好吧，沒事，現在大家感覺壓力已經有點大了，為啥呢？因為每天多 10 萬條數據，一個月就多 300 萬條數據，現在咱們單表已經幾百萬數據了，馬上就破千萬了。但是勉強還能撐著。高峰期請求現在是 1000，咱們線上部署了幾臺機器，負載均衡搞了一下，數據庫撐 1000QPS 也還湊合。但是大家現在開始感覺有點擔心了，接下來咋整呢......
再接下來幾個月，我的天，CEO 太牛逼了，公司用戶數已經達到 1 億，公司繼續融資幾十億人民幣啊！公司估值達到了驚人的幾十億美金，成為了國內今年最牛逼的明星創業公司！天，我們太幸運了。
但是我們同時也是不幸的，因為此時每天活躍用戶數上千萬，每天單表新增數據多達 50 萬，目前一個表總數據量都已經達到了兩三千萬了！扛不住啊！數據庫磁盤容量不斷消耗掉！高峰期併發達到驚人的 5000~8000！別開玩笑了，哥。我跟你保證，你的系統支撐不到現在，已經掛掉了！
好吧，所以你看到這裡差不多就理解分庫分表是怎麼回事兒了，實際上這是跟著你的公司業務發展走的，你公司業務發展越好，用戶就越多，數據量越大，請求量越大，那你單個數據庫一定扛不住。
（2）分表
比如你單表都幾千萬數據了，你確定你能扛住麼？絕對不行，單表數據量太大，會極大影響你的 sql 執行的性能，到了後面你的 sql 可能就跑的很慢了。一般來說，就以我的經驗來看，單表到幾百萬的時候，性能就會相對差一些了，你就得分表了。
分表是啥意思？就是把一個表的數據放到多個表中，然後查詢的時候你就查一個表。比如按照用戶 id 來分表，將一個用戶的數據就放在一個表中。然後操作的時候你對一個用戶就操作那個表就好了。這樣可以控制每個表的數據量在可控的範圍內，比如每個表就固定在 200 萬以內。
（4）分庫
分庫是啥意思？就是你一個庫一般我們經驗而言，最多支撐到併發 2000，一定要擴容了，而且一個健康的單庫併發值你最好保持在每秒 1000 左右，不要太大。那麼你可以將一個庫的數據拆分到多個庫中，訪問的時候就訪問一個庫好了。
這就是所謂的分庫分表，為啥要分庫分表？你明白了吧。
# 分庫分表前 分庫分表後 併發支撐情況 MySQL 單機部署，扛不住高併發 MySQL從單機到多機，能承受的併發增加了多倍 磁盤使用情況 MySQL 單機磁盤容量幾乎撐滿 拆分為多個庫，數據庫服務器磁盤使用率大大降低 SQL 執行性能 單表數據量太大，SQL 越跑越慢 單表數據量減少，SQL 執行效率明顯提升
02 用過哪些分庫分表中間件？不同的分庫分表中間件都有什麼優點和缺點？
這個其實就是看看你瞭解哪些分庫分表的中間件，各個中間件的優缺點是啥？然後你用過哪些分庫分表的中間件。
（1）比較常見的包括：
- Cobar
- TDDL
- Atlas
- Sharding-jdbc
- Mycat
（2）Cobar
阿里 b2b 團隊開發和開源的，屬於 proxy 層方案，就是介於應用服務器和數據庫服務器之間。應用程序通過 JDBC 驅動訪問 Cobar 集群，Cobar 根據 SQL 和分庫規則對 SQL 做分解，然後分發到 MySQL 集群不同的數據庫實例上執行。早些年還可以用，但是最近幾年都沒更新了，基本沒啥人用，差不多算是被拋棄的狀態吧。而且不支持讀寫分離、存儲過程、跨庫 join 和分頁等操作。
（3）TDDL
淘寶團隊開發的，屬於 client 層方案。支持基本的 crud 語法和讀寫分離，但不支持 join、多表查詢等語法。目前使用的也不多，因為還依賴淘寶的 diamond 配置管理系統。
（4）Atlas
360 開源的，屬於 proxy 層方案，以前是有一些公司在用的，但是確實有一個很大的問題就是社區最新的維護都在 5 年前了。所以，現在用的公司基本也很少了。
（5）Sharding-jdbc
噹噹開源的，屬於 client 層方案，目前已經更名為 ShardingSphere（後文所提到的 Sharding-jdbc，等同於 ShardingSphere）。確實之前用的還比較多一些，因為 SQL 語法支持也比較多，沒有太多限制，而且截至 2019.4，已經推出到了 4.0.0-RC1 版本，支持分庫分表、讀寫分離、分佈式 id 生成、柔性事務（最大努力送達型事務、TCC 事務）。而且確實之前使用的公司會比較多一些（這個在官網有登記使用的公司，可以看到從 2017 年一直到現在，是有不少公司在用的），目前社區也還一直在開發和維護，還算是比較活躍，個人認為算是一個現在也可以選擇的方案。
（6）Mycat
基於 Cobar 改造的，屬於 proxy 層方案，支持的功能非常完善，而且目前應該是非常火的而且不斷流行的數據庫中間件，社區很活躍，也有一些公司開始在用了。但是確實相比於 Sharding jdbc 來說，年輕一些，經歷的錘鍊少一些。
03 你們具體是如何對數據庫如何進行垂直拆分或水平拆分的？
水平拆分 的意思，就是把一個表的數據給弄到多個庫的多個表裡去，但是每個庫的表結構都一樣，只不過每個庫表放的數據是不同的，所有庫表的數據加起來就是全部數據。水平拆分的意義，就是將數據均勻放更多的庫裡，然後用多個庫來扛更高的併發，還有就是用多個庫的存儲容量來進行擴容。
垂直拆分的意思，就是把一個有很多字段的表給拆分成多個表，或者是多個庫上去。每個庫表的結構都不一樣，每個庫表都包含部分字段。一般來說，會將較少的訪問頻率很高的字段放到一個表裡去，然後將較多的訪問頻率很低的字段放到另外一個表裡去。因為數據庫是有緩存的，你訪問頻率高的行字段越少，就可以在緩存裡緩存更多的行，性能就越好。這個一般在表層面做的較多一些。
這個其實挺常見的，不一定我說，大家很多同學可能自己都做過，把一個大表拆開，訂單表、訂單支付表、訂單商品表。
還有表層面的拆分，就是分表，將一個表變成 N 個表，就是讓每個表的數據量控制在一定範圍內，保證 SQL 的性能。否則單表數據量越大，SQL 性能就越差。一般是 200 萬行左右，不要太多，但是也得看具體你怎麼操作，也可能是 500 萬，或者是 100 萬。你的SQL越複雜，就最好讓單錶行數越少。
好了，無論分庫還是分表，上面說的那些數據庫中間件都是可以支持的。就是基本上那些中間件可以做到你分庫分表之後，中間件可以根據你指定的某個字段值，比如說 userid，自動路由到對應的庫上去，然後再自動路由到對應的表裡去。
你就得考慮一下，你的項目裡該如何分庫分表？一般來說，垂直拆分，你可以在表層面來做，對一些字段特別多的表做一下拆分；水平拆分，你可以說是併發承載不了，或者是數據量太大，容量承載不了，你給拆了，按什麼字段來拆，你自己想好；分表，你考慮一下，你如果哪怕是拆到每個庫裡去，併發和容量都 ok 了，但是每個庫的表還是太大了，那麼你就分表，將這個表分開，保證每個表的數據量並不是很大。
而且這兒還有兩種分庫分表的方式：
- 一種是按照 range 來分，就是每個庫一段連續的數據，這個一般是按比如時間範圍來的，但是這種一般較少用，因為很容易產生熱點問題，大量的流量都打在最新的數據上了。
- 或者是按照某個字段 hash 一下均勻分散，這個較為常用。
range 來分，好處在於說，擴容的時候很簡單，因為你只要預備好，給每個月都準備一個庫就可以了，到了一個新的月份的時候，自然而然，就會寫新的庫了；缺點，但是大部分的請求，都是訪問最新的數據。實際生產用 range，要看場景。
hash 分發，好處在於說，可以平均分配每個庫的數據量和請求壓力；壞處在於說擴容起來比較麻煩，會有一個數據遷移的過程，之前的數據需要重新計算 hash 值重新分配到不同的庫或表。
最後
除了這數據庫4連問之外，下面還準備了20個高頻數據庫的知識點（含詳細解析）以及數據庫的性能優化21個最佳實踐（PDF）
有需要的話可以 轉發+ 後臺 私信 “數據庫” 免費領取~~
- 數據庫的高頻面試知識點（含詳細的解析）
- 事務四大特性（ACID）原子性、一致性、隔離性、持久性？
- 事務的併發？事務隔離級別，每個級別會引發什麼問題，MySQL默認是哪個級別？
- MySQL常見的三種存儲引擎（InnoDB、MyISAM、MEMORY）的區別？
- MySQL的MyISAM與InnoDB兩種存儲引擎在，事務、鎖級別，各自的適用場景？
- 查詢語句不同元素（where、jion、limit、group by、having等等）執行先後順序？
- 什麼是臨時表，臨時表什麼時候刪除?
- MySQL B+Tree索引和Hash索引的區別？
- sql查詢語句確定創建哪種類型的索引？如何優化查詢？
- 聚集索引和非聚集索引區別？
- 有哪些鎖（樂觀鎖悲觀鎖），select 時怎麼加排它鎖？
- 非關係型數據庫和關係型數據庫區別，優勢比較？
- 數據庫三範式，根據某個場景設計數據表？
- 數據庫的讀寫分離、主從複製，主從複製分析的 7 個問題？
- 使用explain優化sql和索引？
- MySQL慢查詢怎麼解決？
- 什麼是 內連接、外連接、交叉連接、笛卡爾積等？
- mysql都有什麼鎖，死鎖判定原理和具體場景，死鎖怎麼解決？
- varchar和char的使用場景？
- mysql 高併發環境解決方案？
- 數據庫崩潰時事務的恢復機制（REDO日誌和UNDO日誌）？
詳細解答如下所示：
20個高頻數據庫的知識點（含詳細解析）
- 數據庫的性能優化21個最佳實踐（PDF）
- 為優化你的查詢
- EXPLAIN你的SELECT查詢
- 當只要一行數據時使用LIMIT 1
- 為搜索字段建索引
- 在Join表的時候使用相當類型的例，並將其索引
- 千萬不要 ORDER BY RAND()
- 避免 SELECT *
- 永遠為每張表設置一個 ID
- 使用 ENUM 而不是 VARCHAR
- 從 PROCEDURE ANALYSE() 取得建議
- 儘可能的使用 NOT NULL
- Prepared Statements
- 無緩衝的查詢
- 把 IP 地址存成 UNSIGNED INT
- 固定長度的表會更快
- 垂直分割
- 拆分大的 DELETE 或 INSERT 語句
- 越小的列會越快
- 選擇正確的存儲引擎
- 使用一個對象關係映射器(Object Relational Mapper)
- 小心“永久鏈接”
數據庫全家桶
最後說一次，如果你對數據庫感興趣，需要這些整理的數據庫資料，
轉發+轉發+私信“數據庫”即可免費領取！！！！
閱讀更多 追逐仰望星空 的文章
