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