今天給大家帶來的討論主題是通過實戰經驗來對百億數據量下的多表數據查詢進行優化，俗話說的好，一切脫離業務的架構都是耍流氓，接下來我就整理一下今天早上微信群里石頭哥給大家分享的百億數據量多表查詢架構以及優化思路。由于本文內容整理自微信群，爬樓不易，整理更不易，如果有遺漏，歡迎大家在評論區留言。

簡單引子一個例子引出主題

?

這里我們先舉個簡單的例子，來個開胃菜，然后再引出今天的訪談主題。

舉例：比如我們的CzarCms系統權限系統設計中的兩張表：用戶表以及角色表，這兩張表有關聯關系。這時候如果我要取一萬個用戶的數據，然后用戶數據又需要關聯角色表來查詢對應的角色名稱，這時候你會怎么做呢？

按照以往我們的經驗我們會對大表進行盡可能的拆分，能分表就分表。我們在取數據的時候使用下join查詢即可實現。

可是，當我們的系統變得足夠大的時候，假設我們的用戶表有一百萬的用戶了，角色表也有近10萬的數據，這個時候我們如果還繼續使用Join進行查詢的時候就會變得非常慢了！

這時候我們可以改變下思路：就是先把一萬條用戶數據取出來，然后取所有角色id后再去重的組合，然后用一個查詢把所有的角色信息取出來，再在內存中進行相應的拼接處理。這種思路勉強能夠支撐。

可是如果數據量變得越來越大，這時候我們應該如何來進行處理呢？且看下面來自百億數據實操的經典訪談。

業務場景分析實際業務觸發

場景介紹

這里，石頭哥就以他們公司的實際情況為例來進行了相關的實例闡述：

我們的主要表，都是幾億到幾十億行，一個join不小心就可以弄死數據庫,

而且每天1億包裹在路上，產生3億多掃描數據

數據存儲最少T+1，保存完整的一個月，也就是30到60天

數據量90到180億

這里面，最常見的就是省,市,區,網點,人員，這5個字段

很久以前，我們只有三五百萬業務量的時候，大家都是join五次

后來為了省事，用了10個字段，提前把名稱寫進去

再后來，發現虧大了

多花了好多空間，并且join不一定是只需要名稱字段

于是，進入了新時代，所有數據表都有那基本的5個字段，不許join

查詢出來數據后，在內存中再關聯省，市，區，網點，人員等信息

地區5萬行，網點3萬行，人員100萬，全部提前加載到內存，加起來不到100M

我們小部門有100臺服務器，絕大部分用到這些基礎數據

不僅僅上百億的掃描表，其它業務表，幾乎都會帶有這些字段，所以，緩存基礎數據，不吃虧

互動環節

1. 多大的數據量，才不能用join？

答：一般來說，從表100萬以內，我們都建議內存緩存，10萬以內必須用進程內緩存，沒得商量，內存中進行關聯即可。

2. 我們刪數據只能一條條刪。不允許批刪除，這個怎么辦？

答：你們DBA可以辭退了，這么簡單的事情都不會。

大數據分析的時候，每個月幾個億數據，一條條刪，刪到何年何月啊，當然是整個分區干掉啦

3. 可以分享一下你們的緩存方案嗎？

這個就不用了吧，我覺得很多大佬關于緩存的文章就寫得非常好！

我這里只補充一些量化的數字：內存速度是Redis速度100倍，Redis緩存速度是數據庫至少10倍。

10萬以內數據量必須緩存在進程內，100萬~1億數據緩存在Redis，10萬~100萬可以上下商量，超高查詢量（比如每天10億次）時放內存。

很多文章真的寫得挺好的，就是少了點經驗數據支撐，讀者搞不清楚什么時候該用這個，什么時候該用那個。

4. 吉吉：以下場景：假設緩存了地區，比如查詢人員檔案信息列表是1萬行? 以前是關聯查詢? 現在緩存地區不能關聯查詢? 只能查出一萬條然后循環拼接地區顯示? ，因為一萬行顯示本身這場景就不可能，所以增加翻頁 一頁顯示20行? 完全不會性能問題? 這樣做對嗎 求教？

答：是的，查詢一頁20行，理論上要去匹配20次地區，但是地區數據少，省市區才四五千行，省市區加上鄉鎮街道也不過5萬行，可以全量緩存到內存。

吉吉：明白? 謝謝? 只是舉例? 這種思路真的很正確? ?我們總是從技術考慮全部場景卻不考慮產品本身根本不能一勞永逸的搞。

5. 真是太牛逼了！感謝分享

答：這么Low的辦法，大家都可以想得到，只是可能缺少一個遇到這個數據量的機會罷了，這是咱們.net的際遇，遇到問題可以見招拆招.

6. 你說的緩存到進程內，那多個進程內數據怎么保持一致？

答：不保持一致，因為進程級緩存，可以定時更新的，我們方案是默認10秒異步更新緩存，然后也可以按照添刪改隨時更新。

7. 我的內存數據以哪個為準？如果我機器是負載均衡，那么幾個副本內存不一樣啊！

答：以本機為準,沒關系，每臺服務器上都有一份緩存。緩存10萬用戶信息，一共也就10M左右內存，你還在意？

8. 數據怎么進行存儲呢？

答：內存字典進行存儲，最常用的就是并行字典 ConcurrentDictionary。

9. 假設你說的人員數據，那就必然存在 某一時刻 A進程10000人，B進程10002人，可能十秒可能八秒，但你們體量這么大，這個問題不需要處理嗎

答：沒錯，的確存在這樣的問題，我們公司有100萬人員，但是全公司都知道，新加一個帳號，往往要兩三天才能在100多個內部系統全部生效，甚至新簽約一家網點，也要兩三天以后，各個系統才會認它，等你有那個體量的時候，就可以接受更長的不一致時間，我們在淘寶開店，發布商品，有時候發布成功了，跳轉到詳情頁卻是看不到的，等幾秒就好了。

另外，

我再說一句惡心一點的情況，大家別拍磚啊，在百億級數據量之下，就算我算錯個幾百幾千，那又怎么樣？？？又怎么樣？？

對內，我會嚴格要求部門人員，務必追求準確；

對外，我會反復提醒部門人員，我們提供的數據精度，最高99.99%，你要敢浪費大量時間在0.01%上，我就敢給你績效C

不用太死板嘛，把整體工作搞定，讓系統穩定工作，那才是咱們的主要工作

用戶有萬分之一的機會看到不正確的數據，只要再刷新一次能夠正確，就一定不是bug

萬分之一看到不正確的數據，并且只是萬分之一的偏差而已

由此換取的好處是，我們再也不用擔心各種該死的“數據一致性。

TOP

1

總結

END

今天非常感謝石頭哥的精彩分享，相信只有實際的業務操作經驗才會有如此深刻的講解！一切從實際業務出發，脫離理論，實踐出真知。還是印證了那句話，一切脫離實際業務的架構都是耍流氓！感謝大家的閱讀。

有想進一步了解石頭哥的可以這篇文章《[論一個程序員的自我修養-從一張圖片說起](https://www.cnblogs.com/yilezhu/p/10249547.html)》?

最后為石頭哥的XCode打個廣告：

NewLife.XCode是一個有10多年歷史的開源數據中間件，支持nfx/netstandard，由新生命團隊(2002~2019)開發完成并維護至今，以下簡稱XCode。

xcode在2018年已經完成對大數據場景的特殊優化改造，2019年的目標是是針對分布式數據場景的優化。

最近石頭哥也在為XCode編寫系列教程：

整個系列教程會大量結合示例代碼和運行日志來進行深入分析，蘊含多年開發經驗于其中，代表作有百億級大數據實時計算項目。

開源地址：[https://github.com/NewLifeX/X ](https://github.com/NewLifeX/X)（求star, 670+）

總結

以上是生活随笔為你收集整理的现身说法：实际业务出发分析百亿数据量下的多表查询优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。