生產真實案例:震驚,幾條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後。

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

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章