一次MySQL反應慢排查

MySQL反應慢排查

前言

話說某天的一個陽光明媚的下午，我正在公司的樓下喝着咖啡，聽着歌。本來心情美滋滋，突然微信收到一條消息：‘現在10.X.X.X MySQL 反應很慢，xx庫反應都很慢’，婉如晴天霹靂，百米沖刺的速度跑到辦公桌前開始排查問題。

第一招 縱覽大局

登入到MySQL系統中，第一件事，先進行

top

來确定一個大範圍。如下幾個比較重要的資訊

load average #目前OS的系統負載，分别是1分鐘，5分鐘，15分鐘。主要目的是确定目前的系統大概的壓力範圍。
 %Cpu(s):  0.0 us,  0.3 sy,  0.0 wa #分别對應使用者執行程式所消耗的資源占CPU的百分比、核心所消耗占CPU的百分比、等待IO輸入輸出占CPU時間百分比
KiB Mem :   481876 total,     9300 free,   269364 used,   203212 buff/cache
KiB Swap:  2096124 total,  2094580 free,     1544 used.   165964 avail Mem

#MEM、SWAP的總量、使用、空閑            

一般情況，在觀察

top

輸出中，如果發現

us

很高，可能是慢查詢，SQL執行效率差導緻，等其他原因導緻的。

如果是

sy

很高，可能是鎖、NUMA等導緻。

wa

很高，可能是MySQL大量使用臨時表、在進行存在備份任務 需要

iotop

在一次确認等。

Mem

中的

free

空閑記憶體較少，請檢查是否發生記憶體洩漏，是否使用大量的記憶體臨時表或者錯誤的參數配置等。

KiB Swap

頻繁使用，請檢查

vm.swappiness

參數和

NUMA

是否關閉。

第二招 細化分析

登入到系統中打開慢查詢日志

tail -0f 慢查詢.log

或者查詢最近期間的慢查詢日志，主要檢查是否有複雜的

SQL

有大量的排序、分組、

like %

等大量不走索引或者需要臨時表操作。

并且登入到MySQL中進行檢視是否有事物未送出，是否有發生鎖等待。

select * from information_schema.INNODB_TRX

檢視大事物。主要觀察目前事物執行狀态和事物執行時間。

select * from information_schema.INNODB_LOCKS

#檢視目前鎖資訊。主要觀察目前有多少行被鎖住

select * from information_schema.PROCESSLIST

#檢視目前的SQL執行情況。主要觀察是否有

Waiting for table metadata lock

或者表鎖、全局讀鎖等SQL。

還有觀察目前的MySQL每秒的

TPS

、

QPS

、目前的連接配接數、錯誤連接配接數。如果你的

TPS

QPS

達到了曆史高峰，并和業務确認是業務猛增，那麼恭喜了。如果是連接配接數達到了高峰期，請和開發同學确認，是否代碼出現了bug，例如連接配接未關閉等。

IO排查需要使用

iotop

pt-ioprofile

sar

等，主要關注每秒的順序和随機寫入、讀取量，目前的隊列數等值。

網絡排查則需要使用

ping 網關orAPP

，檢查是否丢包，是否有延遲。補充知識點

ping

可以指定參數

-l 和 -f

快速檢測丢包和檢測丢包。

總結

上述MySQL反應慢是常見問題，幾乎每個DBA或多或少都遇見過，但每個人使用的工具和排查思路的方式和方法是不一樣的。本文也是簡單介紹一下改如何排查，除了這些方法以外還有其他原因導緻MySQL反應慢嘛，有的 筆者曾經出來過一起故障 MySQL反應慢，MySQL版本是6.0的比較特殊。希望能給你的學習和工作帶來收獲。