前言

大家好，我是撿田螺的小男孩，今天跟大家聊聊分庫(kù)分表。

1. 什么是分庫(kù)分表
2. 為什么需要分庫(kù)分表
3. 如何分庫(kù)分表
4. 什么時(shí)候開始考慮分庫(kù)分表
5. 分庫(kù)分表會(huì)導(dǎo)致哪些問題
6. 分庫(kù)分表中間件簡(jiǎn)介

1. 什么是分庫(kù)分表

分庫(kù)：就是一個(gè)數(shù)據(jù)庫(kù)分成多個(gè)數(shù)據(jù)庫(kù)，部署到不同機(jī)器。

分表：就是一個(gè)數(shù)據(jù)庫(kù)表分成多個(gè)表。

2. 為什么需要分庫(kù)分表

2.1 為什么需要分庫(kù)呢？

如果業(yè)務(wù)量劇增，數(shù)據(jù)庫(kù)可能會(huì)出現(xiàn)性能瓶頸，這時(shí)候我們就需要考慮拆分?jǐn)?shù)據(jù)庫(kù)。從這幾方面來看：

• 磁盤存儲(chǔ)

業(yè)務(wù)量劇增，MySQL單機(jī)磁盤容量會(huì)撐爆，拆成多個(gè)數(shù)據(jù)庫(kù)，磁盤使用率大大降低。

• 并發(fā)連接支撐

我們知道數(shù)據(jù)庫(kù)連接是有限的。在高并發(fā)的場(chǎng)景下，大量請(qǐng)求訪問數(shù)據(jù)庫(kù)，MySQL單機(jī)是扛不住的！當(dāng)前非?；鸬?/span>微服務(wù)架構(gòu)出現(xiàn)，就是為了應(yīng)對(duì)高并發(fā)。它把訂單、用戶、商品等不同模塊，拆分成多個(gè)應(yīng)用，并且把單個(gè)數(shù)據(jù)庫(kù)也拆分成多個(gè)不同功能模塊的數(shù)據(jù)庫(kù)（訂單庫(kù)、用戶庫(kù)、商品庫(kù)），以分擔(dān)讀寫壓力。

2.2 為什么需要分表？

數(shù)據(jù)量太大的話，SQL的查詢就會(huì)變慢。如果一個(gè)查詢SQL沒命中索引，千百萬數(shù)據(jù)量級(jí)別的表可能會(huì)拖垮整個(gè)數(shù)據(jù)庫(kù)。

即使SQL命中了索引，如果表的數(shù)據(jù)量超過一千萬的話，查詢也是會(huì)明顯變慢的。這是因?yàn)樗饕话闶荁+樹結(jié)構(gòu)，數(shù)據(jù)千萬級(jí)別的話，B+樹的高度會(huì)增高，查詢就變慢啦。

小伙伴們是否還記得，MySQL的B+樹的高度怎么計(jì)算的呢？ 順便復(fù)習(xí)一下吧

InnoDB存儲(chǔ)引擎最小儲(chǔ)存單元是頁(yè)，一頁(yè)大小就是16k。B+樹葉子存的是數(shù)據(jù)，內(nèi)部節(jié)點(diǎn)存的是鍵值+指針。索引組織表通過非葉子節(jié)點(diǎn)的二分查找法以及指針確定數(shù)據(jù)在哪個(gè)頁(yè)中，進(jìn)而再去數(shù)據(jù)頁(yè)中找到需要的數(shù)據(jù)，B+樹結(jié)構(gòu)圖如下：

假設(shè)B+樹的高度為2的話，即有一個(gè)根結(jié)點(diǎn)和若干個(gè)葉子結(jié)點(diǎn)。這棵B+樹的存放總記錄數(shù)為=根結(jié)點(diǎn)指針數(shù)*單個(gè)葉子節(jié)點(diǎn)記錄行數(shù)。

• 如果一行記錄的數(shù)據(jù)大小為1k，那么單個(gè)葉子節(jié)點(diǎn)可以存的記錄數(shù) =16k/1k =16.
• 非葉子節(jié)點(diǎn)內(nèi)存放多少指針呢？我們假設(shè)主鍵ID為bigint類型，長(zhǎng)度為8字節(jié)(面試官問你int類型，一個(gè)int就是32位，4字節(jié))，而指針大小在InnoDB源碼中設(shè)置為6字節(jié)，所以就是 8+6=14 字節(jié)，16k/14B =16*1024B/14B = 1170

因此，一棵高度為2的B+樹，能存放1170 * 16=18720條這樣的數(shù)據(jù)記錄。同理一棵高度為3的B+樹，能存放1170 *1170 *16 =21902400，大概可以存放兩千萬左右的記錄。B+樹高度一般為1-3層，如果B+到了4層，查詢的時(shí)候會(huì)多查磁盤的次數(shù)，SQL就會(huì)變慢。

因此單表數(shù)據(jù)量太大，SQL查詢會(huì)變慢，所以就需要考慮分表啦。

3. 如何分庫(kù)分表

3.1 垂直拆分

3.1.1 垂直分庫(kù)

在業(yè)務(wù)發(fā)展初期，業(yè)務(wù)功能模塊比較少，為了快速上線和迭代，往往采用單個(gè)數(shù)據(jù)庫(kù)來保存數(shù)據(jù)。數(shù)據(jù)庫(kù)架構(gòu)如下：

但是隨著業(yè)務(wù)蒸蒸日上，系統(tǒng)功能逐漸完善。這時(shí)候，可以按照系統(tǒng)中的不同業(yè)務(wù)進(jìn)行拆分，比如拆分成用戶庫(kù)、訂單庫(kù)、積分庫(kù)、商品庫(kù)，把它們部署在不同的數(shù)據(jù)庫(kù)服務(wù)器，這就是垂直分庫(kù)。

垂直分庫(kù)，將原來一個(gè)單數(shù)據(jù)庫(kù)的壓力分擔(dān)到不同的數(shù)據(jù)庫(kù)，可以很好應(yīng)對(duì)高并發(fā)場(chǎng)景。數(shù)據(jù)庫(kù)垂直拆分后的架構(gòu)如下：

3.1.2 垂直分表

如果一個(gè)單表包含了幾十列甚至上百列，管理起來很混亂，每次都select *的話，還占用IO資源。這時(shí)候，我們可以將一些不常用的、數(shù)據(jù)較大或者長(zhǎng)度較長(zhǎng)的列拆分到另外一張表。

比如一張用戶表，它包含user_id、user_name、mobile_no、age、email、nickname、address、user_desc，如果email、address、user_desc等字段不常用，我們可以把它拆分到另外一張表，命名為用戶詳細(xì)信息表。這就是垂直分表

3.2 水平拆分

3.2.1 水平分庫(kù)

水平分庫(kù)是指，將表的數(shù)據(jù)量切分到不同的數(shù)據(jù)庫(kù)服務(wù)器上，每個(gè)服務(wù)器具有相同的庫(kù)和表，只是表中的數(shù)據(jù)集合不一樣。它可以有效地緩解單機(jī)單庫(kù)的性能瓶頸和壓力。

用戶庫(kù)的水平拆分架構(gòu)如下：

3.2.2 水平分表

如果一個(gè)表的數(shù)據(jù)量太大，可以按照某種規(guī)則（如hash取模、range），把數(shù)據(jù)切分到多張表去。

一張訂單表，按時(shí)間range拆分如下：

3.3. 水平分庫(kù)分表策略

分庫(kù)分表策略一般有幾種，使用于不同的場(chǎng)景：

• range范圍
• hash取模
• range+hash取?；旌?/span>

3.3.1 range范圍

range，即范圍策略劃分表。比如我們可以將表的主鍵，按照從0~1000萬劃分為一個(gè)表，1000~2000萬劃分到另外一個(gè)表。如下圖：

當(dāng)然，有時(shí)候我們也可以按時(shí)間范圍來劃分，如不同年月的訂單放到不同的表，它也是一種range的劃分策略。

這種方案的優(yōu)點(diǎn)：

• 這種方案有利于擴(kuò)容，不需要數(shù)據(jù)遷移。假設(shè)數(shù)據(jù)量增加到5千萬，我們只需要水平增加一張表就好啦，之前0~4000萬的數(shù)據(jù)，不需要遷移。

缺點(diǎn)：

• 這種方案會(huì)有熱點(diǎn)問題，因?yàn)橛唵蝘d是一直在增大的，也就是說最近一段時(shí)間都是匯聚在一張表里面的。比如最近一個(gè)月的訂單都在1000萬~2000萬之間，平時(shí)用戶一般都查最近一個(gè)月的訂單比較多，請(qǐng)求都打到order_1表啦，這就導(dǎo)致數(shù)據(jù)熱點(diǎn)問題。

3.3.2 hash取模

hash取模策略：指定的路由key（一般是user_id、訂單id作為key）對(duì)分表總數(shù)進(jìn)行取模，把數(shù)據(jù)分散到各個(gè)表中。

比如原始訂單表信息，我們把它分成4張分表：

• 比如id=1，對(duì)4取模，就會(huì)得到1，就把它放到t_order_1;
• id=3，對(duì)4取模，就會(huì)得到3，就把它放到t_order_3;

這種方案的優(yōu)點(diǎn)：

• hash取模的方式，不會(huì)存在明顯的熱點(diǎn)問題。

缺點(diǎn)：

• 如果一開始按照hash取模分成4個(gè)表了，未來某個(gè)時(shí)候，表數(shù)據(jù)量又到瓶頸了，需要擴(kuò)容，這就比較棘手了。比如你從4張表，又?jǐn)U容成8張表，那之前id=5的數(shù)據(jù)是在（5%4=1，即t_order_1），現(xiàn)在應(yīng)該放到（5%8=5，即t_order_5），也就是說歷史數(shù)據(jù)要做遷移了。

3.3.3 range+hash取模混合

既然range存在熱點(diǎn)數(shù)據(jù)問題，hash取模擴(kuò)容遷移數(shù)據(jù)比較困難，我們可以綜合兩種方案一起嘛，取之之長(zhǎng)，棄之之短。

比較簡(jiǎn)單的做法就是，在拆分庫(kù)的時(shí)候，我們可以先用range范圍方案，比如訂單id在0~4000萬的區(qū)間，劃分為訂單庫(kù)1;id在4000萬~8000萬的數(shù)據(jù)，劃分到訂單庫(kù)2,將來要擴(kuò)容時(shí)，id在8000萬~1.2億的數(shù)據(jù)，劃分到訂單庫(kù)3。然后訂單庫(kù)內(nèi)，再用hash取模的策略，把不同訂單劃分到不同的表。

4. 什么時(shí)候才考慮分庫(kù)分表呢？

4.1 什么時(shí)候分表？

如果你的系統(tǒng)處于快速發(fā)展時(shí)期，如果每天的訂單流水都新增幾十萬，并且，訂單表的查詢效率明變慢時(shí)，就需要規(guī)劃分庫(kù)分表了。一般B+樹索引高度是2~3層最佳，如果數(shù)據(jù)量千萬級(jí)別，可能高度就變4層了，數(shù)據(jù)量就會(huì)明顯變慢了。不過業(yè)界流傳，一般500萬數(shù)據(jù)就要考慮分表了。

4.2 什么時(shí)候分庫(kù)

業(yè)務(wù)發(fā)展很快，還是多個(gè)服務(wù)共享一個(gè)單體數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)成為了性能瓶頸，就需要考慮分庫(kù)了。比如訂單、用戶等，都可以抽取出來，新搞個(gè)應(yīng)用（其實(shí)就是微服務(wù)思想），并且拆分?jǐn)?shù)據(jù)庫(kù)（訂單庫(kù)、用戶庫(kù)）。

5. 分庫(kù)分表會(huì)導(dǎo)致哪些問題

分庫(kù)分表之后，也會(huì)存在一些問題：

• 事務(wù)問題
• 跨庫(kù)關(guān)聯(lián)
• 排序問題
• 分頁(yè)問題
• 分布式ID

5.1 事務(wù)問題

分庫(kù)分表后，假設(shè)兩個(gè)表在不同的數(shù)據(jù)庫(kù)，那么本地事務(wù)已經(jīng)無效啦，需要使用分布式事務(wù)了。

5.2 跨庫(kù)關(guān)聯(lián)

跨節(jié)點(diǎn)Join的問題：解決這一問題可以分兩次查詢實(shí)現(xiàn)

5.3 排序問題

跨節(jié)點(diǎn)的count,order by,group by以及聚合函數(shù)等問題：可以分別在各個(gè)節(jié)點(diǎn)上得到結(jié)果后在應(yīng)用程序端進(jìn)行合并。

5.4 分頁(yè)問題

• 方案1：在個(gè)節(jié)點(diǎn)查到對(duì)應(yīng)結(jié)果后，在代碼端匯聚再分頁(yè)。
• 方案2：把分頁(yè)交給前端，前端傳來pageSize和pageNo，在各個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)都執(zhí)行分頁(yè)，然后匯聚總數(shù)量前端。這樣缺點(diǎn)就是會(huì)造成空查，如果分頁(yè)需要排序，也不好搞。

5.5 分布式ID

數(shù)據(jù)庫(kù)被切分后，不能再依賴數(shù)據(jù)庫(kù)自身的主鍵生成機(jī)制啦，最簡(jiǎn)單可以考慮UUID，或者使用雪花算法生成分布式ID。

6. 分庫(kù)分表中間件

目前流行的分庫(kù)分表中間件比較多：

• cobar
• Mycat
• Sharding-JDBC
• Atlas
• TDDL（淘寶）
• vitess

最后

如果這篇文章對(duì)您有所幫助，或者有所啟發(fā)的話，求一鍵三連：點(diǎn)贊、轉(zhuǎn)發(fā)、在看，您的支持是我堅(jiān)持寫作最大的動(dòng)力。

來源：
https://mp.weixin.qq.com/s/JmgRkVM5J6Wj8lbqH6iX1g