一次MySQL慢查詢招致的毛病

一次MySQL慢查詢招致的毛病。本站提示廣大學習愛好者：（一次MySQL慢查詢招致的毛病）文章只能為提供參考，不一定能成為您想要的結果。以下是一次MySQL慢查詢招致的毛病正文

我們曉得剖析MySQL語句查詢機能的辦法除應用EXPLAIN 輸入履行籌劃，還可讓MySQL記載下查詢跨越指准時間的語句，我們將跨越指准時間的SQL語句查詢稱為“慢查詢”。

1、 原由
研發反響某台數據庫僵逝世，前面的會話要末銜接不上，要末要消費年夜量的時光前往成果，哪怕是一個簡略的查詢。

2、 處置
起首去監控平台檢查辦事器和數據庫狀況，發明這台數據庫有年夜量的慢查詢。持續看辦事器監控，CPU 均勻應用率較高，IO 讀寫均勻值正常。登錄到 MySQL，應用 SHOW PROCESSLIST 檢查會話狀況，總數竟然有 600+，這是很不正常的。檢查慢查詢日記，發明出成績的 SQL 重要集中在幾個，有 SUM、有 COUNT、有等值操作等等。這台 MySQL 辦事器的 long_query_time 設置為 3秒，而一個簡略的查詢卻要幾十秒，這明顯是有成績的。寫劇本試著 kill 失落相干的會話，發明於事無補，依然有年夜量的銜接出去。此時應用 top 檢查辦事器狀況，mysqld 過程占用內存和 CPU 居高不下。

毛病時代的慢查詢數，如圖：

CPU 均勻應用率，如圖：

接著應用 SHOW FULL PROCESSLIST 檢查完全狀況，在最下面竟然發明幾條 SQL。這些 SQL 操作應用子查詢完成，TIME 列竟然到達了 30000 秒，折算過去差不多 10 小時。EXPLAIN 這些語句，竟然湧現了 USING TEMPORY 和 USING FILESORT，可以看出這些語句是很蹩腳的。因而跟開辟確認，緊迫把這些會話 kill 失落。稍等少焉，會話數立馬降上去，只要 100+，top 檢查 mysqld 過程，內存和 CPU 都出現降低的趨向。接著剖析開辟說上午 9 時寫了這些 SQL，發明有成績，正文失落了。新的代碼固然沒有此類 SQL，但之前樹立的銜接其實不會釋放。處理成績和湧現成績的時光差恰好可以和添加子查詢的時光對應，便可以確認子查詢是此次毛病的禍首罪魁。

3、 總結
經由過程這個毛病，總結以下幾點：

• MySQL 應當盡可能防止應用子查詢，即便應用，也要弄清晰年夜表和小表的關系；
• 湧現這類成績的排查步調：

第一，檢查辦事器監控和 MySQL 監控，剖析辦事器和 MySQL 機能，找出異常；
第二，假如是慢查詢招致，檢查慢查詢日記，找出湧現成績的 SQL，試著優化，或許把成果緩存；
第三，分清主次，先處理年夜塊成績，後處理渺小成績。 把年夜塊的異常處理，小成績就水到渠成了。好比本文中的例子，把消耗時光長的會話 kill 失落後，前面的銜接就正常了；
第四，總結剖析。

• 高效的溝通會事半功倍；
• DBA 須要按期給出 Top N SQL（類 Oracle 的說法），供給給開辟，並協助優化；
• 檢查監控時，不論是辦事器監控照樣 MySQL 監控，須要做比較，好比和昨天乃至前天的統一時光比較，這會加倍疾速地定位成績。

4、 技能
最初，附上一個疾速kill 失落 MySQL 會話的辦法：

起首應用以下語句剖析出有成績的 SQL：

/usr/local/mysql/bin/mysql -uroot -p'XXX' \ -e "SHOW FULL PROCESSLIST;" | more

然後將 SHOW FULL PROCESSLIST 的成果保留到一個文件：

/usr/local/mysql/bin/mysql -uroot -p'XXX' \
-e "SHOW FULL PROCESSLIST;" | \
grep "XXX" | awk '{print $1}' > mysql_slow.txt

最初應用以下簡略的 Shell 劇本 kill 失落相干會話：

SELECT concat('kill ',id,';')
FROM information_schema.processlist
WHERE info like 'XXX';

固然也能夠應用以下 SQL 拼接 kill 語句：

SELECT concat('kill ',id,';')
FROM information_schema.processlist
WHERE info like 'XXX';

本文對MySQL慢查詢招致毛病的原由，處置辦法，所需的技能停止了周全剖析，願望可讓年夜家更好的懂得MySQL慢查詢，對年夜家的。