大家好，我是冰河~~

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

事件背景

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

事件經(jīng)過

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

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

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

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

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

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

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

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

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

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

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

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

不知道是不是因?yàn)槿豪镉兴麄兝习宓木壒剩@貨后面還在狡辯。

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

處理結(jié)果

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

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

事后總結(jié)

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

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

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

頓時(shí)讓我想到了一句話：人的認(rèn)知有幾個(gè)層次：不知道自己不知道，知道自己不知道，知道自己知道，不知道自己知道。

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

總結(jié)

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

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