當(dāng)業(yè)務(wù)規(guī)模達(dá)到一定規(guī)模之后，像淘寶日訂單量在5000萬單以上，美團(tuán)3000萬單以上。數(shù)據(jù)庫面對海量的數(shù)據(jù)壓力，分庫分表就是必須進(jìn)行的操作了。而分庫分表之后一些常規(guī)的查詢可能都會(huì)產(chǎn)生問題，最常見的就是比如分頁查詢的問題。一般我們把分表的字段稱作shardingkey，比如訂單表按照用戶ID作為shardingkey，那么如果查詢條件中不帶用戶ID查詢怎么做分頁？又比如更多的多維度的查詢都沒有shardingkey又怎么查詢？

唯一主鍵

一般我們數(shù)據(jù)庫的主鍵都是自增的，那么分表之后主鍵沖突的問題就是一個(gè)無法避免的問題，最簡單的辦法就是以一個(gè)唯一的業(yè)務(wù)字段作為唯一的主鍵，比如訂單表的訂單號(hào)肯定是全局唯一的。 常見的分布式生成唯一ID的方式很多，最常見的雪花算法Snowflake、滴滴Tinyid、美團(tuán)Leaf。以雪花算法舉例來說，一毫秒可以生成4194304多個(gè)ID。第一位不使用，默認(rèn)都是0，41位時(shí)間戳精確到毫秒，可以容納69年的時(shí)間，10位工作機(jī)器ID高5位是數(shù)據(jù)中心ID，低5位是節(jié)點(diǎn)ID，12位序列號(hào)每個(gè)節(jié)點(diǎn)每毫秒累加，累計(jì)可以達(dá)到2^12 4096個(gè)ID。

分表

第一步，分表后要怎么保證訂單號(hào)的唯一搞定了，現(xiàn)在考慮下分表的問題。首先根據(jù)自身的業(yè)務(wù)量和增量來考慮分表的大小。 舉個(gè)例子，現(xiàn)在我們?nèi)諉瘟渴?0萬單，預(yù)估一年后可以達(dá)到日100萬單，根據(jù)業(yè)務(wù)屬性，一般我們就支持查詢半年內(nèi)的訂單，超過半年的訂單需要做歸檔處理。 那么以日訂單100萬半年的數(shù)量級來看，不分表的話我們訂單量將達(dá)到100萬X180=1.8億，以這個(gè)數(shù)據(jù)量級部分表的話肯定單表是扛不住的，就算你能扛RT的時(shí)間你也根本無法接受吧。根據(jù)經(jīng)驗(yàn)單表幾百萬的數(shù)量對于數(shù)據(jù)庫是沒什么壓力的，那么只要分256張表就足夠了，1.8億/256≈70萬，如果為了保險(xiǎn)起見，也可以分到512張表。那么考慮一下，如果業(yè)務(wù)量再增長10倍達(dá)到1000萬單每天，分表1024就是比較合適的選擇。 通過分表加上超過半年的數(shù)據(jù)歸檔之后，單表70萬的數(shù)據(jù)就足以應(yīng)對大部分場景了。接下來對訂單號(hào)hash，然后對256取模的就可以落到具體的哪張表了。

那么，因?yàn)槲ㄒ恢麈I都是以訂單號(hào)作為依據(jù)，以前你寫的那些根據(jù)主鍵ID做查詢的就不能用了，這就涉及到了歷史一些查詢功能的修改。不過這都不是事兒對吧，都改成以訂單號(hào)來查就行了。這都不是問題，問題在我們的標(biāo)題說的點(diǎn)上。

C端查詢

說了半天，總算到了正題了，那么分表之后查詢和分頁查詢的問題怎么解決？ 首先說帶shardingkey的查詢，比如就通過訂單號(hào)查詢，不管你分頁還是怎么樣都是能直接定位到具體的表來查詢的，顯然查詢是不會(huì)有什么問題的。 如果不是shardingkey的話，上面舉例說的以訂單號(hào)作為shardingkey的話，像APP、小程序這種一般都是通過用戶ID查詢，那這時(shí)候我們通過訂單號(hào)做的sharding怎么辦？很多公司訂單表直接用用戶ID做shardingkey，那么很簡單，直接查就完了。那么訂單號(hào)怎么辦，一個(gè)很簡單的辦法就是在訂單號(hào)上帶上用戶ID的屬性。舉個(gè)很簡單的例子，原本41位的時(shí)間戳你覺得用不完，用戶ID是10位的，訂單號(hào)的生成規(guī)則帶上用戶ID，落具體表的時(shí)候根據(jù)訂單號(hào)中10位用戶ID hash取模，這樣無論根據(jù)訂單號(hào)還是用戶ID查詢效果都是一樣的。 當(dāng)然，這種方式只是舉例，具體的訂單號(hào)生成的規(guī)則，多少位，包含哪些因素根據(jù)自己的業(yè)務(wù)和實(shí)現(xiàn)機(jī)制來決定。

好，那么無論你是訂單號(hào)還是用戶ID作為shardingkey，按照以上的兩種方式都可以解決問題了。那么還有一個(gè)問題就是如果既不是訂單號(hào)又不是用戶ID查詢怎么辦？最直觀的例子就是來自商戶端或者后臺(tái)的查詢，商戶端都是以商戶或者說賣家的ID作為查詢條件來查的，后臺(tái)的查詢條件可能就更復(fù)雜了，像我碰到的有些后臺(tái)查詢條件能有幾十個(gè)，這怎么查？？？別急，接下來分開說B端和后臺(tái)的復(fù)雜查詢。 現(xiàn)實(shí)中真正的流量大頭都是來自于用戶端C端，所以本質(zhì)上解決了用戶端的問題，這個(gè)問題就解了大半，剩下來自商戶賣家端B端、后臺(tái)支持運(yùn)營業(yè)務(wù)的查詢流量并不會(huì)很大，這個(gè)問題就好解。

其他端查詢

針對B端的非shardingkey的查詢有兩個(gè)辦法解決。雙寫，雙寫就是下單的數(shù)據(jù)落兩份，C端和B端的各自保存一份，C端用你可以用單號(hào)、用戶ID做shardingkey都行，B端就用商家賣家的ID作為shardingkey就好了。有些同學(xué)會(huì)說了，你雙寫不影響性能嗎？因?yàn)閷τ贐端來說輕微的延遲是可以接受的，所以可以采取異步的方式去落B端訂單。你想想你去淘寶買個(gè)東西下單了，賣家稍微延遲個(gè)一兩秒收到這個(gè)訂單的消息有什么關(guān)系嗎？你點(diǎn)個(gè)外賣商戶晚一兩秒收到這個(gè)訂單有什么太大影響嗎？

這是一個(gè)解決方案，另外一個(gè)方案就是走離線數(shù)倉或者ES查詢，訂單數(shù)據(jù)落庫之后，不管你通過binlog還是MQ消息的都形式，把數(shù)據(jù)同步到數(shù)倉或者ES，他們支持的數(shù)量級對于這種查詢條件來說就很簡單了。同樣這種方式肯定是稍微有延遲的，但是這種可控范圍的延遲是可以接受的。

而針對管理后臺(tái)的查詢，比如運(yùn)營、業(yè)務(wù)、產(chǎn)品需要看數(shù)據(jù)，他們天然需要復(fù)雜的查詢條件，同樣走ES或者數(shù)倉都可以做得到。如果不用這個(gè)方案，又要不帶shardingkey的分頁查詢，兄弟，這就只能掃全表查詢聚合數(shù)據(jù)，然后手動(dòng)做分頁了，但是這樣查出來的結(jié)果是有限制的。 比如你256個(gè)片，查詢的時(shí)候循環(huán)掃描所有的分片，每個(gè)片取20條數(shù)據(jù)，最后聚合數(shù)據(jù)手工分頁，那必然是不可能查到全量的數(shù)據(jù)的。

總結(jié)

分庫分表后的查詢問題，對于有經(jīng)驗(yàn)的同學(xué)來說其實(shí)這個(gè)問題都知道，但是我相信其實(shí)大部分同學(xué)做的業(yè)務(wù)可能都沒來到這個(gè)數(shù)量級，分庫分表可能都停留在概念階段，面試被問到后就手足無措了，因?yàn)闆]有經(jīng)驗(yàn)不知道怎么辦。 分庫分表首先是基于現(xiàn)有的業(yè)務(wù)量和未來的增量做出判斷，比如拼多多這種日單量5000萬的，半年數(shù)據(jù)得有百億級別了，那都得分到4096張表了對吧，但是實(shí)際的操作是一樣的，對于你們的業(yè)務(wù)分4096那就沒有必要了，根據(jù)業(yè)務(wù)做出合理的選擇。 對于基于shardingkey的查詢我們可以很簡單的解決，對于非shardingkey的查詢可以通過落雙份數(shù)據(jù)和數(shù)倉、ES的方案來解決，當(dāng)然，如果分表后數(shù)據(jù)量很小的話，建好索引，掃全表查詢其實(shí)也不是什么問題。

責(zé)任編輯：xj

原文標(biāo)題：百億級數(shù)據(jù)分表后，該怎么分頁查詢？

文章出處：【微信公眾號(hào)：數(shù)據(jù)分析與開發(fā)】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。