當業務規模達到一定規模之後，像**日訂單量在5000萬單以上，美團3000萬單以上。資料庫面對海量的資料壓力，分庫分表就是必須進行的操作了。而分庫分表之後一些常規的查詢可能都會產生問題，最常見的就是比如分頁查詢的問題。一般我們把分表的字段稱作shardingkey，比如訂單表按照使用者id作為shardingkey，那麼如果查詢條件中不帶使用者id查詢怎麼做分頁？又比如更多的多維度的查詢都沒有shardingkey又怎麼查詢？
一般我們資料庫的主鍵都是自增的，那麼分表之後主鍵衝突的問題就是乙個無法避免的問題，最簡單的辦法就是以乙個唯一的業務字段作為唯一的主鍵，比如訂單表的訂單號肯定是全域性唯一的。
常見的分布式生成唯一id的方式很多，最常見的雪花演算法snowflake、滴滴tinyid、美團leaf。以雪花演算法舉例來說，一毫秒可以生成4194304多個id。
第一位不使用，預設都是0，41位時間戳精確到毫秒，可以容納69年的時間，10位工作機器id高5位是資料中心id，低5位是節點id，12位序列號每個節點每毫秒累加，累計可以達到2^12 4096個id。
第一步，分表後要怎麼保證訂單號的唯一搞定了，現在考慮下分表的問題。首先根據自身的業務量和增量來考慮分表的大小。
舉個例子，現在我們日單量是10萬單，預估一年後可以達到日100萬單，根據業務屬性，一般我們就支援查詢半年內的訂單，超過半年的訂單需要做歸檔處理。
那麼以日訂單100萬半年的數量級來看，不分表的話我們訂單量將達到100萬x180=1.8億，以這個資料量級部分表的話肯定單錶是扛不住的，就算你能扛rt的時間你也根本無法接受吧。根據經驗單錶幾百萬的數量對於資料庫是沒什麼壓力的，那麼只要分256張表就足夠了，1.8億/256≈70萬，如果為了保險起見，也可以分到512張表。那麼考慮一下，如果業務量再增長10倍達到1000萬單每天，分表1024就是比較合適的選擇。
通過分表加上超過半年的資料歸檔之後，單錶70萬的資料就足以應對大部分場景了。接下來對訂單號hash，然後對256取模的就可以落到具體的哪張表了。
那麼，因為唯一主鍵都是以訂單號作為依據，以前你寫的那些根據主鍵id做查詢的就不能用了，這就涉及到了歷史一些查詢功能的修改。不過這都不是事兒對吧，都改成以訂單號來查就行了。這都不是問題，問題在我們的標題說的點上。
說了半天，總算到了正題了，那麼分表之後查詢和分頁查詢的問題怎麼解決？
首先說帶shardingkey的查詢，比如就通過訂單號查詢，不管你分頁還是怎麼樣都是能直接定位到具體的表來查詢的，顯然查詢是不會有什麼問題的。
當然，這種方式只是舉例，具體的訂單號生成的規則，多少位，包含哪些因素根據自己的業務和實現機制來決定。
好，那麼無論你是訂單號還是使用者id作為shardingkey，按照以上的兩種方式都可以解決問題了。那麼還有乙個問題就是如果既不是訂單號又不是使用者id查詢怎麼辦？最直觀的例子就是來自商戶端或者後台的查詢，商戶端都是以商戶或者說賣家的id作為查詢條件來查的，後台的查詢條件可能就更複雜了，像我碰到的有些後台查詢條件能有幾十個，這怎麼查？？？別急，接下來分開說b端和後台的複雜查詢。
現實中真正的流量大頭都是來自於使用者端c端，所以本質上解決了使用者端的問題，這個問題就解了大半，剩下來自商戶賣家端b端、後台支援運營業務的查詢流量並不會很大，這個問題就好解。
針對b端的非shardingkey的查詢有兩個辦法解決。
雙寫，雙寫就是下單的資料落兩份，c端和b端的各自儲存乙份，c端用你可以用單號、使用者id做shardingkey都行，b端就用商家賣家的id作為shardingkey就好了。有些同學會說了，你雙寫不影響效能嗎？因為對於b端來說輕微的延遲是可以接受的，所以可以採取非同步的方式去落b端訂單。你想想你去**買個東西下單了，賣家稍微延遲個一兩秒收到這個訂單的訊息有什麼關係嗎？你點個外賣商戶晚一兩秒收到這個訂單有什麼太大影響嗎？
這是乙個解決方案，另外乙個方案就是走脫機數倉或者es查詢，訂單資料落庫之後，不管你通過binlog還是mq訊息的都形式，把資料同步到數倉或者es，他們支援的數量級對於這種查詢條件來說就很簡單了。同樣這種方式肯定是稍微有延遲的，但是這種可控範圍的延遲是可以接受的。
而針對管理後台的查詢，比如運營、業務、產品需要看資料，他們天然需要複雜的查詢條件，同樣走es或者數倉都可以做得到。如果不用這個方案，又要不帶shardingkey的分頁查詢，兄弟，這就只能掃全表查詢聚合資料，然後手動做分頁了，但是這樣查出來的結果是有限制的。
比如你256個片，查詢的時候迴圈掃瞄所有的分片，每個片取20條資料，最後聚合資料手工分頁，那必然是不可能查到全量的資料的。
分庫分表後的查詢問題，對於有經驗的同學來說其實這個問題都知道，但是我相信其實大部分同學做的業務可能都沒來到這個數量級，分庫分表可能都停留在概念階段，面試被問到後就手足無措了，因為沒有經驗不知道怎麼辦。
分庫分表首先是基於現有的業務量和未來的增量做出判斷，比如拼多多這種日單量5000萬的，半年資料得有百億級別了，那都得分到4096張表了對吧，但是實際的操作是一樣的，對於你們的業務分4096那就沒有必要了，根據業務做出合理的選擇。
對於基於shardingkey的查詢我們可以很簡單的解決，對於非shardingkey的查詢可以通過落雙份資料和數倉、es的方案來解決，當然，如果分表後資料量很小的話，建好索引，掃全表查詢其實也不是什麼問題。
百億級資料處理優化
最近在做大資料處理時，遇到兩個大表 join 導致資料處理太慢 甚至算不出來 的問題。我們的數倉基於阿里的 odps，它與 hive 類似，所以這篇文章也適用於使用 hive 優化。處理優化問題，一般是先指定一些常用的優化引數，但是當設定引數仍然不奏效的時候，我們就要結合具體的業務，在 sql 上做...
海量資料分頁
language vbscript codepage 936 分頁sql語句生成 function getpagesql tblname,fldname,pagesize,pageindex,ordertype,strwhere dim strtemp,strsql,strorder 根據排序方式生...
Sql Server 資料分頁
1 引言 在列表查詢時由於資料量非常多，一次性查出來會非常慢，就算一次查出來了，也不能一次性顯示給客戶端，所以要把資料進行分批查詢出來，每頁顯示一定量的資料，這就是資料要分頁。2 常用的資料分頁語法 先查出 top 300000，再聚合取這個集合中最大的id1，再過濾 id大於id1的集合 上圖中使...