我們?nèi)ッ嬖嚨臅r(shí)候，幾乎都會(huì)被問(wèn)到分庫(kù)分表。

在這里整理了分庫(kù)分表的15道經(jīng)典面試題，大家看完肯定會(huì)有幫助的。

1. 我們?yōu)槭裁葱枰謳?kù)分表

在分庫(kù)分表之前，就需要考慮為什么需要拆分。我們做一件事，肯定是有充分理由的。所以得想好分庫(kù)分表的理由是什么。我們現(xiàn)在就從兩個(gè)維度去思考它，為什么要分庫(kù)？為什么要分表？

1.1 為什么要分庫(kù)

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

• 磁盤(pán)存儲(chǔ)

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

• 并發(fā)連接支撐

我們知道數(shù)據(jù)庫(kù)連接數(shù)是有限的。在高并發(fā)的場(chǎng)景下，大量請(qǐng)求訪問(wèn)數(shù)據(jù)庫(kù)，MySQL單機(jī)是扛不住的！高并發(fā)場(chǎng)景下，會(huì)出現(xiàn)too many connections報(bào)錯(cuò)。

當(dāng)前非常火的微服務(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)讀寫(xiě)壓力。

1.2 為什么要分表

假如你的單表數(shù)據(jù)量非常大，存儲(chǔ)和查詢的性能就會(huì)遇到瓶頸了，如果你做了很多優(yōu)化之后還是無(wú)法提升效率的時(shí)候，就需要考慮做分表了。一般千萬(wàn)級(jí)別數(shù)據(jù)量，就需要分表。

這是因?yàn)榧词?code style="font-size:14px;padding:2px 4px;margin-right:2px;margin-left:2px;background-color:rgba(27,31,35,.05);font-family:'Operator Mono', Consolas, Monaco, Menlo, monospace;color:rgb(100,149,237);">SQL命中了索引，如果表的數(shù)據(jù)量超過(guò)一千萬(wàn)的話，查詢也是會(huì)明顯變慢的。這是因?yàn)樗饕话闶?code style="font-size:14px;padding:2px 4px;margin-right:2px;margin-left:2px;background-color:rgba(27,31,35,.05);font-family:'Operator Mono', Consolas, Monaco, Menlo, monospace;color:rgb(100,149,237);">B+樹(shù)結(jié)構(gòu)，數(shù)據(jù)千萬(wàn)級(jí)別的話，B+樹(shù)的高度會(huì)增高，查詢就變慢啦。MySQL的B+樹(shù)的高度怎么計(jì)算的呢？跟大家復(fù)習(xí)一下：

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

假設(shè)B+樹(shù)的高度為2的話，即有一個(gè)根結(jié)點(diǎn)和若干個(gè)葉子結(jié)點(diǎn)。這棵B+樹(shù)的存放總記錄數(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é)(面試官問(wèn)你int類型，一個(gè)int就是32位，4字節(jié))，而指針大小在InnoDB源碼中設(shè)置為6字節(jié)，所以就是 8+6=14 字節(jié)，16k/14B =16*1024B/14B = 1170

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

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

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

對(duì)于MySQL，InnoDB存儲(chǔ)引擎的話，單表最多可以存儲(chǔ)10億級(jí)數(shù)據(jù)。但是的話，如果真的存儲(chǔ)這么多，性能就會(huì)非常差。一般數(shù)據(jù)量千萬(wàn)級(jí)別，B+樹(shù)索引高度就會(huì)到3層以上了，查詢的時(shí)候會(huì)多查磁盤(pán)的次數(shù)，SQL就會(huì)變慢。

阿里巴巴的《Java開(kāi)發(fā)手冊(cè)》提出：

單表行數(shù)超過(guò)500萬(wàn)行或者單表容量超過(guò)2GB，才推薦進(jìn)行分庫(kù)分表。

那我們是不是等到數(shù)據(jù)量到達(dá)五百萬(wàn)，才開(kāi)始分庫(kù)分表呢？

不是這樣的，我們應(yīng)該提前規(guī)劃分庫(kù)分表，如果估算3年后，你的表都不會(huì)到達(dá)這個(gè)五百萬(wàn)，則不需要分庫(kù)分表。

MySQL服務(wù)器如果配置更好，是不是可以超過(guò)這個(gè)500萬(wàn)這個(gè)量級(jí)，才考慮分庫(kù)分表？

雖然配置更好，可能數(shù)據(jù)量大之后，性能還是不錯(cuò)，但是如果持續(xù)發(fā)展的話，還是要考慮分庫(kù)分表

一般什么類型業(yè)務(wù)表需要才分庫(kù)分表？

通用是一些流水表、用戶表等才考慮分庫(kù)分表，如果是一些配置類的表，則完全不用考慮，因?yàn)椴惶赡艿竭_(dá)這個(gè)量級(jí)。

3. 如何選擇分表鍵

分表鍵，即用來(lái)分庫(kù)/分表的字段，換種說(shuō)法就是，你以哪個(gè)維度來(lái)分庫(kù)分表的。比如你按用戶ID分表、按時(shí)間分表、按地區(qū)分表，這些用戶ID、時(shí)間、地區(qū)就是分表鍵。

一般數(shù)據(jù)庫(kù)表拆分的原則，需要先找到業(yè)務(wù)的主題。比如你的數(shù)據(jù)庫(kù)表是一張企業(yè)客戶信息表，就可以考慮用了客戶號(hào)做為分表鍵。

為什么考慮用客戶號(hào)做分表鍵呢？

這是因?yàn)楸硎腔诳蛻粜畔⒌?，所以，需要將同一個(gè)客戶信息的數(shù)據(jù)，落到一個(gè)表中，避免觸發(fā)全表路由。

4.非分表鍵如何查詢

分庫(kù)分表后，有時(shí)候無(wú)法避免一些業(yè)務(wù)場(chǎng)景，需要通過(guò)非分表鍵來(lái)查詢。

假設(shè)一張用戶表，根據(jù)userId做分表鍵，來(lái)分庫(kù)分表。但是用戶登錄時(shí)，需要根據(jù)用戶手機(jī)號(hào)來(lái)登陸。這時(shí)候，就需要通過(guò)手機(jī)號(hào)查詢用戶信息。而手機(jī)號(hào)是非分表鍵。

非分表鍵查詢，一般有這幾種方案：

• 遍歷：最粗暴的方法，就是遍歷所有的表，找出符合條件的手機(jī)號(hào)記錄（不建議）
• 將用戶信息冗余同步到ES，同步發(fā)送到ES，然后通過(guò)ES來(lái)查詢（推薦）

其實(shí)還有基因法：比如非分表鍵可以解析出分表鍵出來(lái)，比如常見(jiàn)的，訂單號(hào)生成時(shí)，可以包含客戶號(hào)進(jìn)去，通過(guò)訂單號(hào)查詢，就可以解析出客戶號(hào)。但是這個(gè)場(chǎng)景除外，手機(jī)號(hào)似乎不適合冗余userId。

5. 分表策略如何選擇

5.1 range范圍

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

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

• 優(yōu)點(diǎn)： range范圍分表，有利于擴(kuò)容。
• 缺點(diǎn)：可能會(huì)有熱點(diǎn)問(wèn)題。因?yàn)?code style="font-size:14px;padding:2px 4px;margin-right:2px;margin-left:2px;background-color:rgba(27,31,35,.05);font-family:'Operator Mono', Consolas, Monaco, Menlo, monospace;color:rgb(100,149,237);">訂單id是一直在增大的，也就是說(shuō)最近一段時(shí)間都是匯聚在一張表里面的。比如最近一個(gè)月的訂單都在300萬(wàn)~600萬(wàn)之間，平時(shí)用戶一般都查最近一個(gè)月的訂單比較多，請(qǐng)求都打到order_1表啦。

5.2 hash取模

hash取模策略：

指定的路由key（一般是user_id、order_id、customer_no作為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;

一般，我們會(huì)取哈希值，再做取余：

Math.abs(orderId.hashCode())%table_number

• 優(yōu)點(diǎn)：hash取模的方式，不會(huì)存在明顯的熱點(diǎn)問(wèn)題。
• 缺點(diǎn)：如果未來(lái)某個(gè)時(shí)候，表數(shù)據(jù)量又到瓶頸了，需要擴(kuò)容，就比較麻煩。所以一般建議提前規(guī)劃好，一次性分夠。（可以考慮一致性哈希）

5.3 一致性Hash

如果用hash方式分表，前期規(guī)劃不好，需要擴(kuò)容二次分表，表的數(shù)量需要增加，所以hash值需要重新計(jì)算，這時(shí)候需要遷移數(shù)據(jù)了。

比如我們開(kāi)始分了10張表，之后業(yè)務(wù)擴(kuò)展需要，增加到20張表。那問(wèn)題就來(lái)了，之前根據(jù)orderId取模10后的數(shù)據(jù)分散在了各個(gè)表中，現(xiàn)在需要重新對(duì)所有數(shù)據(jù)重新取模20來(lái)分配數(shù)據(jù)

為了解決這個(gè)擴(kuò)容遷移問(wèn)題，可以使用一致性hash思想來(lái)解決。

一致性哈希：在移除或者添加一個(gè)服務(wù)器時(shí)，能夠盡可能小地改變已存在的服務(wù)請(qǐng)求與處理請(qǐng)求服務(wù)器之間的映射關(guān)系。一致性哈希解決了簡(jiǎn)單哈希算法在分布式哈希表存在的動(dòng)態(tài)伸縮等問(wèn)題

6. 如何避免熱點(diǎn)問(wèn)題數(shù)據(jù)傾斜（熱點(diǎn)數(shù)據(jù)）

如果我們根據(jù)時(shí)間范圍分片，某電商公司11月搞營(yíng)銷活動(dòng)，那么大部分的數(shù)據(jù)都落在11月份的表里面了，其他分片表可能很少被查詢，即數(shù)據(jù)傾斜了，有熱點(diǎn)數(shù)據(jù)問(wèn)題了。

我們可以使用range范圍+ hash哈希取模結(jié)合的分表策略，簡(jiǎn)單的做法就是：

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

7.分庫(kù)后，事務(wù)問(wèn)題如何解決

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

常用的分布式事務(wù)解決方案有：

• 兩階段提交
• 三階段提交
• TCC
• 本地消息表
• 最大努力通知
• saga

8. 跨節(jié)點(diǎn)Join關(guān)聯(lián)問(wèn)題

在單庫(kù)未拆分表之前，我們?nèi)绻褂?code style="font-size:14px;padding:2px 4px;margin-right:2px;margin-left:2px;background-color:rgba(27,31,35,.05);font-family:'Operator Mono', Consolas, Monaco, Menlo, monospace;color:rgb(100,149,237);">join關(guān)聯(lián)多張表操作的話，簡(jiǎn)直so easy啦。但是分庫(kù)分表之后，兩張表可能都不在同一個(gè)數(shù)據(jù)庫(kù)中了，那么如何跨庫(kù)join操作呢？

跨庫(kù)Join的幾種解決思路：

• 字段冗余：把需要關(guān)聯(lián)的字段放入主表中，避免關(guān)聯(lián)操作；比如訂單表保存了賣(mài)家ID（sellerId），你把賣(mài)家名字sellerName也保存到訂單表，這就不用去關(guān)聯(lián)賣(mài)家表了。這是一種空間換時(shí)間的思想。
• 全局表：比如系統(tǒng)中所有模塊都可能會(huì)依賴到的一些基礎(chǔ)表（即全局表），在每個(gè)數(shù)據(jù)庫(kù)中均保存一份。
• 數(shù)據(jù)抽象同步：比如A庫(kù)中的a表和B庫(kù)中的b表有關(guān)聯(lián)，可以定時(shí)將指定的表做同步，將數(shù)據(jù)匯合聚集，生成新的表。一般可以借助ETL工具。
• 應(yīng)用層代碼組裝：分開(kāi)多次查詢，調(diào)用不同模塊服務(wù)，獲取到數(shù)據(jù)后，代碼層進(jìn)行字段計(jì)算拼裝。

9. order by,group by等聚合函數(shù)問(wèn)題

跨節(jié)點(diǎn)的count,order by,group by以及聚合函數(shù)等問(wèn)題，都是一類的問(wèn)題，它們一般都需要基于全部數(shù)據(jù)集合進(jìn)行計(jì)算?？梢苑謩e在各個(gè)節(jié)點(diǎn)上得到結(jié)果后，再在應(yīng)用程序端進(jìn)行合并。

10. 分庫(kù)分表后的分頁(yè)問(wèn)題

• 方案1（全局視野法）：在各個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)查到對(duì)應(yīng)結(jié)果后，在代碼端匯聚再分頁(yè)。這樣優(yōu)點(diǎn)是業(yè)務(wù)無(wú)損，精準(zhǔn)返回所需數(shù)據(jù)；缺點(diǎn)則是會(huì)返回過(guò)多數(shù)據(jù)，增大網(wǎng)絡(luò)傳輸

比如分庫(kù)分表前，你是根據(jù)創(chuàng)建時(shí)間排序，然后獲取第2頁(yè)數(shù)據(jù)。如果你是分了兩個(gè)庫(kù)，那你就可以每個(gè)庫(kù)都根據(jù)時(shí)間排序，然后都返回2頁(yè)數(shù)據(jù)，然后把兩個(gè)數(shù)據(jù)庫(kù)查詢回來(lái)的數(shù)據(jù)匯總，再根據(jù)創(chuàng)建時(shí)間進(jìn)行內(nèi)存排序，最后再取第2頁(yè)的數(shù)據(jù)。

• 方案2（業(yè)務(wù)折衷法-禁止跳頁(yè)查詢）：這種方案需要業(yè)務(wù)妥協(xié)一下，只有上一頁(yè)和下一頁(yè)，不允許跳頁(yè)查詢了。

這種方案，查詢第一頁(yè)時(shí)，是跟全局視野法一樣的。但是下一頁(yè)時(shí)，需要把當(dāng)前最大的創(chuàng)建時(shí)間傳過(guò)來(lái)，然后每個(gè)節(jié)點(diǎn)，都查詢大于創(chuàng)建時(shí)間的一頁(yè)數(shù)據(jù)，接著匯總，內(nèi)存排序返回。

11. 分布式ID

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

雪花算法是一種生成分布式全局唯一ID的算法，生成的ID稱為Snowflake IDs。這種算法由Twitter創(chuàng)建，并用于推文的ID。

一個(gè)Snowflake ID有64位。

• 第1位：Java中l(wèi)ong的最高位是符號(hào)位代表正負(fù)，正數(shù)是0，負(fù)數(shù)是1，一般生成ID都為正數(shù)，所以默認(rèn)為0。
• 接下來(lái)前41位是時(shí)間戳，表示了自選定的時(shí)期以來(lái)的毫秒數(shù)。
• 接下來(lái)的10位代表計(jì)算機(jī)ID，防止沖突。
• 其余12位代表每臺(tái)機(jī)器上生成ID的序列號(hào)，這允許在同一毫秒內(nèi)創(chuàng)建多個(gè)Snowflake ID。

12. 分庫(kù)分表選擇哪種中間件

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

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

我們項(xiàng)目當(dāng)前就是使用Sharding-JDBC實(shí)現(xiàn)的分庫(kù)分表。

13.如何評(píng)估分庫(kù)數(shù)量

• 對(duì)于MySQL來(lái)說(shuō)的話，一般單庫(kù)超過(guò)5千萬(wàn)記錄，DB的壓力就非常大了。所以分庫(kù)數(shù)量多少，需要看單庫(kù)處理記錄能力。
• 如果分庫(kù)數(shù)量少，達(dá)不到分散存儲(chǔ)和減輕DB性能壓力的目的；如果分庫(kù)的數(shù)量多，對(duì)于跨多個(gè)庫(kù)的訪問(wèn)，應(yīng)用程序需要訪問(wèn)多個(gè)庫(kù)。
• 一般是建議分4~10個(gè)庫(kù)，我們公司的企業(yè)客戶信息，就分了10個(gè)庫(kù)。

14.垂直分庫(kù)、水平分庫(kù)、垂直分表、水平分表的區(qū)別

• 水平分庫(kù)：以字段為依據(jù)，按照一定策略（hash、range等），將一個(gè)庫(kù)中的數(shù)據(jù)拆分到多個(gè)庫(kù)中。
• 水平分表：以字段為依據(jù)，按照一定策略（hash、range等），將一個(gè)表中的數(shù)據(jù)拆分到多個(gè)表中。
• 垂直分庫(kù)：以表為依據(jù)，按照業(yè)務(wù)歸屬不同，將不同的表拆分到不同的庫(kù)中。
• 垂直分表：以字段為依據(jù)，按照字段的活躍性，將表中字段拆到不同的表（主表和擴(kuò)展表）中。

15.分表要停服嘛？不停服怎么做？

不用停服。不停服的時(shí)候，應(yīng)該怎么做呢，主要分五個(gè)步驟：

1. 編寫(xiě)代理層，加個(gè)開(kāi)關(guān)（控制訪問(wèn)新的DAO還是老的DAO，或者是都訪問(wèn)），灰度期間，還是訪問(wèn)老的DAO。
2. 發(fā)版全量后，開(kāi)啟雙寫(xiě)，既在舊表新增和修改，也在新表新增和修改。日志或者臨時(shí)表記下新表ID起始值，舊表中小于這個(gè)值的數(shù)據(jù)就是存量數(shù)據(jù)，這批數(shù)據(jù)就是要遷移的。
3. 通過(guò)腳本把舊表的存量數(shù)據(jù)寫(xiě)入新表。
4. 停讀舊表改讀新表，此時(shí)新表已經(jīng)承載了所有讀寫(xiě)業(yè)務(wù)，但是這時(shí)候不要立刻停寫(xiě)舊表，需要保持雙寫(xiě)一段時(shí)間。
5. 當(dāng)讀寫(xiě)新表一段時(shí)間之后，如果沒(méi)有業(yè)務(wù)問(wèn)題，就可以停寫(xiě)舊表啦