系統(tǒng)慢到姥姥家了

上周三早上，一開電腦就看到測(cè)試群炸鍋了。鋪天蓋地都是“頁面刷不出來”、“轉(zhuǎn)圈圈轉(zhuǎn)得我要睡覺了”的抱怨。我們那個(gè)破系統(tǒng)，平時(shí)訪問量一上來就跟老牛拉破車似的，這回徹底趴窩了。領(lǐng)導(dǎo)直接在我工位旁邊敲桌子：“搞快點(diǎn)！用戶投訴電話快把客服打爆了！”我心里苦，這破MySQL數(shù)據(jù)庫，數(shù)據(jù)量也就百來萬條，咋就這德行？

抄起工具開干

第一反應(yīng)先摸出系統(tǒng)監(jiān)控工具看負(fù)載。好家伙，CPU直接飆到90%多，內(nèi)存也快見底了。敲了個(gè)top命令，發(fā)現(xiàn)MySQL這貨吃資源跟餓死鬼投胎一樣。但光知道它餓了沒用，得知道它為啥餓。我反手就祭出SHOW PROCESSLIST，一長溜執(zhí)行列表刷出來，當(dāng)場血壓就上來了——一堆SQL語句掛著“Sending data”狀態(tài)，有的甚至跑了十幾分鐘還沒完！

趕緊鎖定那幾個(gè)跑得最歡的進(jìn)程ID，打開percona toolkit（這玩意兒真是DBA的救命稻草），對(duì)著問題進(jìn)程ID一頓操作：

pt-query-digest --processlist h=localhost --filter '$event->{arg} =~ /PID=12345/'

結(jié)果跳出來幾條長得要命的SQL，定睛一看差點(diǎn)昏古七——有個(gè)查用戶訂單歷史的語句，居然在百萬級(jí)數(shù)據(jù)表里玩全表掃描！連個(gè)像樣的索引都沒有，怪不得慢得像烏龜爬。

給SQL動(dòng)手術(shù)

揪出罪魁禍?zhǔn)拙秃棉k了。先拿EXPLAIN照妖鏡照它一照：

EXPLAIN ｓｅｌｅｃｔ  FROM order_history WHERE user_id=456 ORDER BY create_time DESC;

結(jié)果明晃晃寫著type=ALL，rows列顯示要掃90多萬行。我大腿一拍：“索引兄弟！”。立馬掏出腳本給user_id和create_time這倆字段捆了個(gè)組合索引：

ALTER TABLE order_history ADD INDEX idx_user_time (user_id, create_time);

等索引建完手都在抖。重新執(zhí)行EXPLAIN——type=ref，rows瞬間降到200多！當(dāng)場打開終端試跑原SQL，原來20秒的查詢直接干到0.3秒。邊上的實(shí)習(xí)生小哥都看呆了：“這就...完事了？”

意外收獲的坑

剛想嘚瑟，測(cè)試組老張突然從廁所沖出來：“注冊(cè)頁面崩了！”趕緊查日志，發(fā)現(xiàn)個(gè)新報(bào)錯(cuò)：“Lock wait timeout exceeded”。頭皮一麻，又開SHOW ENGINE INNODB STATUS翻事務(wù)鎖信息，好嘛有張用戶表被某個(gè)凌晨跑數(shù)據(jù)的定時(shí)任務(wù)鎖得死死的。

扭頭就把那個(gè)憨批任務(wù)的SQL拆了：
原來：ｕｐｄａｔｅ user SET vip_level=3 WHERE expire_date < NOW()
改成：分批處理，每次只更新500條，更新完睡0.1秒再接著干。這下鎖沖突直接消失，注冊(cè)功能秒恢復(fù)。

血淚換來的教訓(xùn)

• 監(jiān)控永遠(yuǎn)打頭陣：CPU/內(nèi)存不對(duì)勁立馬查進(jìn)程，別瞎猜
• 慢查詢?nèi)罩臼钦昭R：percona那把日志嚼碎了喂你吃
• EXPLAIN必須焊死在SQL前：沒它分析等于蒙著眼開刀

調(diào)完那天晚上壓測(cè)報(bào)告出來，領(lǐng)導(dǎo)群里發(fā)了個(gè)紅包——峰值處理能力真從原來每分鐘400請(qǐng)求提到600了。雖然離50%還差點(diǎn)，但頁面加載從平均5.7秒干到2秒內(nèi)，測(cè)試組那幫人終于不追著我罵了。這波折騰值了！