MySQL数据库CPU使用率接近100%问题排查经验总结

当数据库CPU使用率靠近100%时，会导致数据库无法迅速处理客户端发起的请求，导致请求超时，业务无法正常进行等问题，因此当数据库发生告警时，需要及时排查和解决问题。本文记录发生该问题的一些排查经验。

一、问题排查

当数据库CPU使用率接近100%时，说明有大量SQL正在执行导致数据库CPU高负荷运行。
这时我们可以根据数据库各项监控指标来排查问题，用华为云RDS服务举例，我们可以在数据库服务监控中心中看到CPU使用率的监控图和QPS监控图。


如上图所示，数据库的QPS监控图表示每秒数据库请求的次数，一般来说，当数据库QPS上升时，表示每秒请求增加，此时CPU使用率也应该增加。因此，QPS和CPU使用率应该是正相关的关系。两者监控图曲线应该相对吻合。

如上图红框所示，如果CPU使用率的变化幅度远大于QPS的变化幅度，那就说明部分数据库请求大量占用了数据库CPU资源，此时就需要进行慢SQL排查。

如果CPU使用率变化幅度和QPS变化幅度差不多，那么可以说是大量数据库请求导致数据库CPU使用率升高，需要排查为何出现大量的数据库请求。

这两种情况，我们都可以在数据库使用show processlist;查看当前数据库线程列表通过检查当前执行中的SQL来排查问题。

show processlist;用来显示当前运行中的线程列表，最多显示100条，使用show full processlist;可以查看所有线程列表。需要注意的是，除了root用户能看到所有正在运行的线程外，其他用户都只能看到用户为自己的线程。

参数	说明
ID	当前线程的唯一标识
User	创建该线程的用户
HOST	创建该线程的客户端ip地址和端口号
DB	当前线程访问的数据库
COMMAND	当前线程请求数据库的类型
TIME	表示线程处于当前状态的时间长短，单位是秒。
STATE	当前线程的状态
INFO	一般显示当前线程执行的SQL语句，此值仅包含语句的前100个字符。要查看完整的语句，请使用SHOW FULL PROCESSLIST。

通过TIME确认SQL的执行时间，来确定SQL是否是慢SQL
通过HOST和端口号定位发送SQL的服务器。
通过INFO检查执行的SQL语句来检查SQL是否正常和定位代码位置。
通过ID来终止异常执行的SQL语句。

找到异常的服务器和代码位置后，就可以从代码层面来判断是正常业务导致CPU上升还是异常代码导致CPU上升。

二、问题优化方案

2.1 慢SQL导致的CPU使用率异常上升

对慢SQL进行优化，是否正常使用索引，是否需要分库分表，是否可以做分页处理等等。

2.2 异常业务逻辑QPS上升，导致CPU使用率上升

异常业务逻辑导致CPU使用率上升的话，对代码进行优化即可

2.3 正常业务逻辑QPS上升，导致CPU使用率上升

正常业务逻辑导致CPU使用率上升，考虑对业务逻辑进行优化，使用Redis缓存数据，使用ES搜索引擎进行搜索，增加数据库资源等等