一次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的比较特殊。希望能给你的学习和工作带来收获。