生產真實案例：震驚，幾條SQL把伺服器幹崩了，事後還大言不慚！

來源：冰河技術

今天跟大家分享一個發生在今天凌晨的真實案例，這篇文章也是我事後臨時寫出來的，處理事情的過程有點無語，又有點氣憤！

事件背景

事情的背景是這樣的：一個朋友今年年初新開了一家公司，自己是公司的老闆，不懂啥技術，主要負責公司的戰略規劃和經營管理，但是他們公司的很多事情他都會過問。手下員工30多人，涵蓋技術、產品、運營和推廣，從成立之初，一直在做一款社交類的APP。平時，我們一直保持聯絡，我有時也會幫他們公司處理下技術問題。

事件經過

今天凌晨，我被電話鈴聲吵醒了，一看是這個朋友打來的，說是他們公司資料庫伺服器CPU被打滿了，並且一直持續這個狀態，他說拉個群，把他們後端Java同事拉進來一起溝通下，讓我幫忙看看是什麼問題，儘快處理下。說話語氣很急，聽的出來事態很嚴重，因為目前正在加大力度推廣，週末使用人數也比較多，出現這種問題著實讓人著急。

後面我加了那個朋友拉的微信群，開始瞭解伺服器出現問題的具體情況，下面就是一些處理的經過了。

注：聊天內容已經獲得授權公佈。

他們後端Java把運維發的監控截圖發出來了，我們繼續跟他溝通。

為啥我說CPU佔用高呢？大家看下他們運維發的圖就知道了。

CPU已經飆升到了400%了，資料庫伺服器基本已經卡死。拿到他給我發的SQL後，我跟他們老闆要了一份他們的資料庫表結構，在我電腦上執行了下查詢計劃。

這不看不知道，一看嚇一跳，一個C端頻繁訪問的介面SQL效能極差，Using temporary、Using filesort、Using join buffer、Block Nested Loop全出來了。

我把這個圖發出去了，也結合他們團隊的實際情況，給出了最佳化的目標建議：SQL中不要出現Using filesort、Block Nested Loop，儘量不要出現Using join buffer和Using temporary，把Using where儘量最佳化到Using Index級別。

說是儘量不要出現Using join buffer和Using temporary，把Using where儘量最佳化到Using Index級別，就是怕他們做不到這點，優先把Using filesort、Block Nested Loop最佳化掉。但是這貨後面說的話實屬把我震驚到了。

我看完他的回覆，直接有點無語：臥槽，不超過500萬rows效率很高？你這SQL 500萬資料效果很高？更讓我無語的是這貨說MySQL一般一億以上資料量開始最佳化，這特麼不是完全扯淡嗎？他說這話時，我大概就知道這貨的水平了。。。

後面我就問他說的這些資料的依據是哪裡來的。

這貨說是什麼大資料高併發MySQL資料庫壓測出來的，稍微有過壓測經驗的應該都知道，壓測一個很重要的前提就是要明確壓測的環境，最起碼要明確壓測環境伺服器的CPU核數和記憶體，直接來句MySQL一億資料是大資料高併發MySQL資料庫壓測出來的結果，這還是MySQL官方的資料。。。。

不知道是不是因為群裡有他們老闆的緣故，這貨後面還在狡辯。

溝通到這裡，我特麼有種想打人的衝動，生產環境所有業務快被資料庫拖死了，資料庫伺服器CPU被幹爆了，監控到慢SQL，並且檢視這些慢SQL的執行計劃，效能非常低下，SQL裡不管是select部分還是where部分大量使用了MySQL自帶的函式，這不慢才怪啊。看這貨處理問題的態度，要是我下面的人，早就讓他捲鋪蓋走人了。

處理結果

後續我跟他們老闆要了一個程式碼只讀許可權的賬號，將程式碼拉取下來後，好傢伙，到處都是這種SQL查詢，要是一兩處還好，把SQL修改並最佳化下，關聯的業務邏輯調整下，再把功能測試下，介面壓測下，沒啥問題就可以發版上線了。

但是，如果到處都是這種SQL的話，那最佳化SQL就要花費一定的時間了，甚至是新發布的重大功能邏輯都要重寫。最終，我跟他們老闆說的是回滾版本吧，最新的功能還是先下線，把新功能的SQL、快取、業務邏輯、介面都最佳化好，壓測沒問題後再重新上線。

事後總結

無論什麼時候，生產環境一旦出現致命問題，第一時間要優先恢復生產環境正常訪問，隨後再認真排查、定位和解決問題，畢竟生產環境一旦出現問題，每一秒流失的都是真金白銀。

搭建技術團隊一定要找靠譜的人，最起碼團隊的核心人員要靠譜，像我朋友團隊的這個技術，在他的認知裡，MySQL執行計劃出現Using temporary、Using filesort、Using join buffer、Block Nested Loop，500W rows效率都很高，殊不知他們生產環境實際主表資料才10幾條，要是真達到500W量級就別查詢了，資料庫直接就趴下了。還有這個MySQL一般一億以上開始最佳化，這個依據我也不知道這貨是從哪裡看到的，並且還說了大資料高併發MySQL資料庫壓測出來的，這不純屬扯淡嗎？

更離譜的是我事後悄悄問了他們老闆，他的工作年限是多久，據說工作10多年了，是位80後。

頓時讓我想到了一句話：人的認知有幾個層次：不知道自己不知道，知道自己不知道，知道自己知道，不知道自己知道。

最後，大家對這次事件有什麼看法，歡迎評論區留言討論。