前 言

??接上期??，到現在為止，我們已經對訂單系統核心接口業務流程有了一定的了解，此時我們可以接一些簡單的需求做了。

同時這個時候，也會有對應的產品經理來和我們對接需求，一般3個月左右，我們處理單系統的日常需求就輕車熟路了。

可能在剛入職的時候，這家初創型互聯網公司累積的用戶量也就10萬，每天活躍2萬，日訂單2萬，如下圖：

對于數據庫中的訂單表而言，如果按照一天2萬個訂單數據量計算，一年也就七八百萬的訂單量，還是可以輕松hold住的。

行業風口，用戶量突增帶來的問題

但是，可能若我們就是這么幸運，剛好遇到了移動互聯網快速發展的幾年。

這個時候，外賣APP的用戶量迅速增長到了100萬，日活用戶20萬，日訂單20萬，訂單單表也從300萬快速達到了2000萬，如下圖：

在這3個月的過程中，我們除了做日常的需求外，還要支持解決線上問題，所以經常會去查詢訂單表。

在查詢訂單表數據的時候，我們會發現隨著訂單數據的增多，訂單查詢sql相應的也會變得越來越慢，比如，你剛入職的時候單表可能就300萬數據量，查詢只需要20ms的樣子，但是現在，單表增長到2000萬，不過查詢一般也都穩定在200ms以下。

某一天，當我們正在沉浸式地寫著代碼時，leader突然找到我們說：“昨天晚上小猛上了一個需求，然后今天突然發現我們訂單sql查詢超過了3s，肯定是昨晚上線的sql有問題，現在我們單表才2000萬數據，MySQL是可以輕松hold住的，小猛今天不在公司，你幫忙排查下問題，然后優化下sql。”

可以想象一下這樣一個場景，當我們打開一個外賣app想點個外賣，想起來上周吃的某個外賣還不錯，就想看看自己點的是哪個商家的外賣，然后滿心歡喜的想要點開自己的歷史訂單列表。

結果等了3s訂單列表都還沒加載出來，也許作為干飯人的我們有著強大的毅力，最后終于等到訂單列表加載出來了，心滿意足選好菜品下單。

但此時我們的腦海中是不是會出現那個bgm：“完了，芭比Q了”，所以這樣的查詢速度是萬萬不能接受的，因為體驗極差。

回過神來的我們，聽完leader說的話后就接下了這個任務，馬上開始著手優化sql了，但是下一秒就遇到一個新的難題，那就是我們根本沒優化過sql，就連MySQL的一次查詢會經歷過哪些過程，你都不是很清楚，更不用提要從哪里開始優化了。

而sql優化的第一步，我們得要先了解一下MySQL一次完整查詢會經歷哪些過程，然后再針對性的優化，MySQL一次完整的查詢的過程呢，我們在下一篇文章會詳細的分析，大家不要著急，這里我們繼續分析下現狀。

偶爾的流量爆發，問題被進一步放大

根據剛才的分析，在上百萬規模的一個用戶群體下，數據庫中一年的訂單數據量搞不好都要上億了，一旦訂單表中的數據達到這樣的一個量級之后，后續訂單sql的性能就開始顯著下降了。

但是，容易被我們忽視的一個場景就是，流量可能偶爾會爆發一下，然后sql查詢較慢的問題會被進一步的放大，那么哪些場景會導致流量在短時間內爆發呢？

其實這種場景就比較多了，比如某一天，我們的外賣APP做了一些促銷活動，或者是某一天競對的APP不幸掛掉了（作為良性競爭倡導者的我們不應該有這種想法，但是萬一呢，是吧？），這些場景下，大量的流量就會在短時間里引爆我們外賣APP。

好的，那我們這里假設就是競對的外賣APP出了一些故障吧，比如競對的評價系統掛掉了，導致店鋪的評價顯示不出來，那這就嚴重了，因為部分用戶的訂餐習慣，是在點外賣前都會先看下店鋪的評價。

結果由于競對外賣APP的評價系統掛了，導致店鋪的評價顯示不出來，那這些用戶可能就都會跑到我們的外賣APP來下單，這個時候，我們外賣APP的流量就會瞬間增大好幾倍。

本來這個時候，我們訂單表一次查詢差不多都需要3s了，現在又發生了流量突增的情況，那就會導致已經存在的問題被進一步的放大，比如一次訂單查詢會直接變為5s，這都是有可能的。

所以，如果我們不對這種場景進行優化，就會失去一些用戶，因為我們自己的外賣APP此時也很卡的話，我們就可能會錯過一次“天賜良機”。

結束語

不過，對于這種千萬級數據的優化大家也不用著急，因為接下來，我們會帶著大家一步步分析這些問題背后的原因，并且會將對應的解決方案進行落地，所以大家一定要好好學習，畢竟機會從來都是留給有準備的人的。