前言

分庫分表，是企業(yè)里面比較常見的針對高并發(fā)、數(shù)據(jù)量大的場景下的一種技術(shù)優(yōu)化方案，所謂"分庫分表"，根本就不是一件事兒，而是三件事兒，他們要解決的問題也都不一樣，這三個事兒分別是"只分庫不分表"、"只分表不分庫”、以及"既分庫又分表"。本文我們一起理解分庫、分表的奧秘。

分庫主要解決的是并發(fā)量大的問題。因為并發(fā)量一旦上來了，那么數(shù)據(jù)庫就可能會成為瓶頸，因為數(shù)據(jù)庫的連接數(shù)是有限的，雖然可以調(diào)整，但是也不是無限調(diào)整的。所以，當(dāng)你的數(shù)據(jù)庫的讀或者寫的QPS過高，導(dǎo)致你的數(shù)據(jù)庫連接數(shù)不足了的時候，就需要考慮分庫了，通過增加數(shù)據(jù)庫實例的方式來提供更多的可用數(shù)據(jù)庫鏈接，從而提升系統(tǒng)的并發(fā)度。

分表主要解決的是數(shù)據(jù)量大的問題。假如你的單表數(shù)據(jù)量非常大，因為并發(fā)不高，數(shù)據(jù)量連接可能還夠，但是存儲和查詢的性能遇到了瓶頸了，你做了很多優(yōu)化之后還是無法提升效率的時候，就需要考慮做分表了。

那么，當(dāng)你的數(shù)據(jù)庫鏈接也不夠了，并且單表數(shù)據(jù)量也很大導(dǎo)致査詢比較慢的時候，就需要做既分庫又分表了

分庫、分表、分庫分表

分庫主要解決的是并發(fā)量大的問題。比較典型的分庫的場景就是我們在做微服務(wù)拆分的時候，就會按照業(yè)務(wù)邊界把各個業(yè)務(wù)的數(shù)據(jù)從一個單一的數(shù)據(jù)庫中拆分開，分別把訂單、物流、商品、會員等數(shù)據(jù)，分別放到單獨的數(shù)據(jù)庫中。

還有就是有的時候可能會需要把歷史訂單挪到歷史庫里面去。這也是分庫的一種具體做法

什么時候分表?

分表主要解決的是數(shù)據(jù)量大的問題。通過將數(shù)據(jù)拆分到多張表中，來減少單表的數(shù)據(jù)量，從而提升查詢速度

一般我們認(rèn)為，單表行數(shù)超過 500 萬行或者單表容量超過 2GB之后，才需要考慮做分庫分表了，小于這個數(shù)據(jù)量，遇到性能問題先建議大家通過其他優(yōu)化來解決，

PS:以上數(shù)據(jù)，是阿里巴巴Java開發(fā)手冊中給出的數(shù)據(jù)，偏保守，根據(jù)實際經(jīng)驗來說，單表抗2000萬數(shù)據(jù)量問題不大，但具體的數(shù)據(jù)里還是要看記錄大小、存儲引擎設(shè)置、硬件配置等。

那如果，既需要解決并發(fā)量大的問題，又需要解決數(shù)據(jù)量大的問題時候。通常情況下，高并發(fā)和數(shù)據(jù)量大的問題都是同時發(fā)生的，所以，我們會經(jīng)常遇到分庫分表需要同時進(jìn)行的情況。

所以，當(dāng)你的數(shù)據(jù)庫鏈接也不夠了，并且單表數(shù)據(jù)量也很大導(dǎo)致査詢比較慢的時候，就需要做既分庫又分表了

橫向拆分和縱向拆分

談及到分庫分表，那就要涉及到該如何做拆分的問題。
通常在做拆分的時候有兩種分法，分別是橫向拆分(水平拆分)和縱向拆分(垂直拆分)。假如我們有一張表，如果把這張表中某一條記錄的多個字段，拆分到多張表中，這種就是縱向拆分。那如果把一張表中的不同的記錄分別放到不同的表中，這種就是橫向拆分。

橫向拆分的結(jié)果是數(shù)據(jù)庫表中的數(shù)據(jù)會分散到多張分表中，使得每一個單表中的數(shù)據(jù)的條數(shù)都有所下降。比如我們可以把不同的用戶的訂單分表拆分放到不同的表中。

縱向拆分的結(jié)果是數(shù)據(jù)庫表中的數(shù)據(jù)的字段數(shù)會變少，使得每一個單表中的數(shù)據(jù)的存儲有所下降。比如我可以把商品詳情信息、價格信息、庫存信息等等分別拆分到不同的表中，

分表字段如何選擇?

在分庫分表的過程中，我們需要有一個字段用來進(jìn)行分表，比如按照用戶分表、按照時間分表、按照地區(qū)分表。這里面的用戶、時間、地區(qū)就是所謂的分表字段。

那么，在選擇這個分表字段的時候，一定要注意，要根據(jù)實際的業(yè)務(wù)情況來做慎重的選擇。
比如說我們要對交易訂單進(jìn)行分表的時候，我們可以選擇的信息有很多，比如買家|d、賣家|d、訂單號、時間、地區(qū)等等，具體應(yīng)該如何選擇呢?

通常，如果有特殊的訴求，比如按照月度匯總、地區(qū)匯總等以外，我們通常建議大家按照買家ld進(jìn)行分表。因為這樣可以避免一個關(guān)鍵的問題那就是--數(shù)據(jù)傾斜(熱點數(shù)據(jù))

1、買家還是賣家

首先，我們先說為什么不按照賣家分表?

因為我們知道，電商網(wǎng)站上面是有很多買家和賣家的，但是，一個大的賣家可能會產(chǎn)生很多訂單，比如像蘇寧易購、當(dāng)當(dāng)?shù)冗@種店鋪，他每天在天貓產(chǎn)生的訂單量就非常的大。如果按照賣家!d分表的話，那同一個賣家的很多訂單都會分到同一張表。

那就會使得有一些表的數(shù)據(jù)量非常的大，但是有些表的數(shù)據(jù)量又很小，這就是發(fā)生了數(shù)據(jù)傾斜。這個賣家的數(shù)據(jù)就變成了熱點數(shù)據(jù)，隨著時間的增長，就會使得這個賣家的所有操作都變得異常緩慢。

但是，買家ID做分表字段就不會出現(xiàn)這類問題，因為不太容易出現(xiàn)一個買家能把數(shù)據(jù)買傾斜了。
但是需要注意的是，我們說按照買家Id做分表，保證的是同一個買家的所有訂單都在同一張表，并不是要給每個買家都單獨分配一張表。

我們在做分表路由的時候，是可以設(shè)定一定的規(guī)則的，比如我們想要分1024張表，那么我們可以用買家ID或者買家ID的hashcode對1024取模，結(jié)果是0000-1023，那么就存儲到對應(yīng)的編號的分表中就行了。

2、賣家查詢怎么辦

如果按照買家Id進(jìn)行了分表，那賣家的查詢怎么辦，這不就意味著要跨表查詢了嗎?
首先，業(yè)務(wù)問題我們要建立在業(yè)務(wù)背景下討論。電商網(wǎng)站訂單查詢有幾種場景?

1. 買家查自己的訂單
2. 賣家查自己的訂單
3. 平臺的小二查用戶的訂單。

首先，我們用買家ID做了分表，那么買家來查詢的時候，是一定可以把買家!D帶過來的，我們直接去對應(yīng)的表里面查詢就行了。

那如果是賣家查呢?賣家查詢的話，同樣可以帶賣家id過來，那么，我們可以有一個基于binlog、fink等準(zhǔn)實時的同步一張賣家維度的分表，這張表只用來查詢，來解決賣家查詢的問題。

本質(zhì)上就是用空間換時間的做法。

不知道大家看到這里會不會有這樣的疑問:同步一張賣家表，這不又帶來了大賣家的熱點問題了嗎?
首先，我們說同步一張賣家維度的表來，但是其實所有的寫操作還是要寫到買家表的，只不過需要準(zhǔn)實時同步的方案同步到賣家表中。也就是說，我們的這個賣家表理論上是沒有業(yè)務(wù)的寫操作，只有讀操作的。

所以，這個賣家?guī)熘恍枰懈咝阅艿淖x就行了，那這樣的話就可以有很多選擇了，比如可以部署到一些配置不用那么高的機(jī)器、或者其實可以干脆就不用MYSQL，而是采用HBASE、PolarDB、Lindorm等數(shù)據(jù)庫就可以了。這些數(shù)據(jù)庫都是可以海量數(shù)據(jù)，并提供高性能查詢的。

還有呢就是，大賣家一般都是可以識別的，提前針對大賣家，把他的訂單，再按照一定的規(guī)則拆分到多張表中。因為只有讀，沒有寫操作，所以拆分多張表也不用考慮事務(wù)的問題。

這里說的沒有寫指的是不會主動操作這張賣家表做更新，他的數(shù)據(jù)都是從買家表同步過來的，這個同步的事務(wù)在買家表已經(jīng)處理過了，賣家表只需要負(fù)責(zé)同步。
賣家更新數(shù)據(jù)也一樣，都是基于訂單號更新的，訂單號上面是帶來分表信息的，直接到買家表去更新，然后同步到賣家表。

3、訂單查詢怎么辦

上面說的都是有買賣家ID的情況，那沒有買賣家ID呢?用訂單號直接查怎么辦呢?

這種問題的解決方案是，在生成訂單號的時候，我們一般會把分表結(jié)果編碼到訂單號中去，因為訂單生成的時候是一定可以知道買家ID的，那么我們就把買家ID的路由結(jié)果比如1023，作為一段固定的值放到訂單號中就行了。這就是所謂的“基因法”

這樣按照訂單號查詢的時候，解析出這段數(shù)字，直接去對應(yīng)分表查詢就好了。
至于還有人問其他的查詢，沒有買賣家ID，也沒訂單號的，那其實就屬于是低頻查詢或者非核心功能査詢了，那就可以用ES等搜索引擎的方案來解決了。就不述了。

總結(jié)

本篇我們對分庫分表有了初步的了解，接下來我們具體討論分庫分表的一些常用方法。