上午A部門反饋a程序超級慢，已經(jīng)處理的任務(wù)刷新不掉，未處理任務(wù)刷新不上了。
先讓測試確認，運維看項目后端服務(wù)日志，也沒找出特別的問題。因研發(fā)請假，這個問題就卡住了。
下午B項目組測試人員反饋后端接口超級慢，原來秒幾百的接口，現(xiàn)在要幾秒才返回數(shù)據(jù)
上業(yè)務(wù)服務(wù)器看系統(tǒng)性能數(shù)據(jù)都正常。初步懷疑是數(shù)據(jù)庫服務(wù)器問題。
進數(shù)據(jù)庫系統(tǒng)，看帶寬，系統(tǒng)負載，磁盤IO都是和往常一樣。
不過CPU的使用率達到80%，40%的us使用，40%的sys使用。
用過show processlist查看進程數(shù)，7百多一點，沒到最大值，正常。
找研發(fā)要來兩個接口慢的sql語句，手動執(zhí)行，
一條執(zhí)行用時7.76s,一條用時3.9s
又到從庫執(zhí)行一遍分別為5s,0.5s
主庫確實比較慢。
看一下慢查詢?nèi)罩荆?.6G
把慢查詢?nèi)罩緜浞?，清空，?0分鐘，又出現(xiàn)很多日志
使用pt-query-digest工具分析：
image.png
image.png
image.png
這個語句超級慢，發(fā)給研發(fā)確定，多表查詢中有一個備份表是沒必要查的，而且備份表很大，導(dǎo)致異常慢。
通過修復(fù)這個BUG，數(shù)據(jù)庫CPU使用率回復(fù)正常。問題解決。
