大家好，我是冰河~~

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

事件背景

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

事件經(jīng)過

今天凌晨，我被電話鈴聲吵醒了，一看是這個朋友打來的，說是他們公司數(shù)據(jù)庫服務(wù)器CPU被打滿了，并且一直持續(xù)這個狀態(tài)，他說拉個群，把他們后端Java同事拉進來一起溝通下，讓我?guī)兔纯词鞘裁磫栴}，盡快處理下。說話語氣很急，聽的出來事態(tài)很嚴(yán)重，因為目前正在加大力度推廣，周末使用人數(shù)也比較多，出現(xiàn)這種問題著實讓人著急。

后面我加了那個朋友拉的微信群，開始了解服務(wù)器出現(xiàn)問題的具體情況，下面就是一些處理的經(jīng)過了。

注：聊天內(nèi)容已經(jīng)獲得授權(quán)公布。

他們后端Java把運維發(fā)的監(jiān)控截圖發(fā)出來了，咱繼續(xù)跟他溝通。

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

CPU已經(jīng)飆升到了400%了，數(shù)據(jù)庫服務(wù)器基本已經(jīng)卡死。拿到他給我發(fā)的SQL后，我跟他們老板要了一份他們的數(shù)據(jù)庫表結(jié)構(gòu)，在我電腦上執(zhí)行了下查詢計劃。

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

我把這個圖發(fā)出去了，也結(jié)合他們團隊的實際情況，給出了優(yōu)化的目標(biāo)建議：SQL中不要出現(xiàn)Using filesort、Block Nested Loop，盡量不要出現(xiàn)Using join buffer和Using temporary，把Using where盡量優(yōu)化到Using Index級別。

說是盡量不要出現(xiàn)Using join buffer和Using temporary，把Using where盡量優(yōu)化到Using Index級別，就是怕他們做不到這點，優(yōu)先把Using filesort、Block Nested Loop優(yōu)化掉。 但是這貨后面說的話實屬把我震驚到了。

我看完他的回復(fù)，直接有點無語：臥槽，不超過500萬rows效率很高？你這SQL 500萬數(shù)據(jù)效果很高？更讓我無語的是這貨說MySQL一般一億以上數(shù)據(jù)量開始優(yōu)化，這特么不是完全扯淡嗎？他說這話時，我大概就知道這貨的水平了。。。

后面我就問他說的這些數(shù)據(jù)的依據(jù)是哪里來的。

這貨說是什么大數(shù)據(jù)高并發(fā)MySQL數(shù)據(jù)庫壓測出來的，稍微有過壓測經(jīng)驗的應(yīng)該都知道，壓測一個很重要的前提就是要明確壓測的環(huán)境，最起碼要明確壓測環(huán)境服務(wù)器的CPU核數(shù)和內(nèi)存，直接來句MySQL一億數(shù)據(jù)是大數(shù)據(jù)高并發(fā)MySQL數(shù)據(jù)庫壓測出來的結(jié)果，這還是MySQL官方的數(shù)據(jù)。。。。

不知道是不是因為群里有他們老板的緣故，這貨后面還在狡辯。

溝通到這里，我特么有種想打人的沖動，生產(chǎn)環(huán)境所有業(yè)務(wù)快被數(shù)據(jù)庫拖死了，數(shù)據(jù)庫服務(wù)器CPU被干爆了，監(jiān)控到慢SQL，并且查看這些慢SQL的執(zhí)行計劃，性能非常低下，SQL里不管是select部分還是where部分大量使用了MySQL自帶的函數(shù)，這不慢才怪啊。看這貨處理問題的態(tài)度，要是我下面的人，早就讓他卷鋪蓋走人了。

處理結(jié)果

后續(xù)我跟他們老板要了一個代碼只讀權(quán)限的賬號，將代碼拉取下來后，好家伙，到處都是這種SQL查詢，要是一兩處還好，把SQL修改并優(yōu)化下，關(guān)聯(lián)的業(yè)務(wù)邏輯調(diào)整下，再把功能測試下，接口壓測下，沒啥問題就可以發(fā)版上線了。

但是，如果到處都是這種SQL的話，那優(yōu)化SQL就要花費一定的時間了，甚至是新發(fā)布的重大功能邏輯都要重寫。最終，我跟他們老板說的是回滾版本吧，最新的功能還是先下線，把新功能的SQL、緩存、業(yè)務(wù)邏輯、接口都優(yōu)化好，壓測沒問題后再重新上線。

事后總結(jié)

無論什么時候，生產(chǎn)環(huán)境一旦出現(xiàn)致命問題，第一時間要優(yōu)先恢復(fù)生產(chǎn)環(huán)境正常訪問，隨后再認真排查、定位和解決問題，畢竟生產(chǎn)環(huán)境一旦出現(xiàn)問題，每一秒流失的都是真金白銀。

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

更離譜的是我事后悄悄問了他們老板，他的工作年限是多久，據(jù)說工作10多年了，是位80后。

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

好了，今天就到這兒吧，我是冰河，我們下期見~~

總結(jié)

以上是生活随笔為你收集整理的生产真实案例：震惊，几条SQL把服务器干崩了，事后还大言不惭！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。