MySQL CPU高负载诊断与优化实战指南

1. 问题现象与初步判断

最近在维护生产环境MySQL数据库时，突然收到监控系统告警：某台数据库服务器的CPU使用率持续超过90%，已经持续了半小时以上。这种异常情况如果不及时处理，轻则导致查询响应变慢，重则可能引发数据库雪崩。

登录服务器后，我习惯性地用top命令确认情况：

bash复制top - 15:30:01 up 30 days,  2:15,  3 users,  load average: 8.21, 7.93, 6.78
Tasks: 215 total,   2 running, 213 sleeping,   0 stopped,   0 zombie
%Cpu(s): 92.3 us,  3.4 sy,  0.0 ni,  3.8 id,  0.0 wa,  0.0 hi,  0.5 si,  0.0 st
KiB Mem : 32779668 total,   721328 free, 26343456 used,  5714884 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  5112348 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
12345 mysql     20   0 25.654g 4.832g  42840 S 187.3 15.4  35:20.12 mysqld

从输出可以清晰看到：

1. mysqld进程CPU占用高达187%（多核累加值）
2. 系统负载平均值超过8（8核机器）
3. 内存使用量也处于高位

这种情况通常意味着MySQL正在执行某些高消耗的查询或遇到了性能瓶颈。接下来需要深入MySQL内部找出具体原因。

2. 诊断工具与方法论

2.1 实时监控工具选择

MySQL提供了多种性能诊断工具，针对CPU高负载场景，我通常会按以下顺序排查：

1. SHOW PROCESSLIST
   快速查看当前执行的SQL语句，适合发现明显的"问题查询"

2. performance_schema
   MySQL 5.6+版本提供的性能监控库，可以获取线程级别的详细统计信息

3. sys schema
   MySQL 5.7+提供的友好视图，将performance_schema数据转化为更易读的格式

4. 慢查询日志
   需要提前开启，适合分析历史性能问题

5. EXPLAIN
   分析特定SQL的执行计划

2.2 诊断流程设计

根据经验，我总结了一套标准排查流程：

1. 确认是否真的由MySQL引起（排除其他进程干扰）
2. 识别高负载时段（对比监控图表）
3. 捕获问题SQL（实时查询+历史分析）
4. 分析执行计划（EXPLAIN工具）
5. 检查系统配置（参数合理性）
6. 验证解决方案（测试环境复现）

3. 详细排查过程

3.1 实时会话分析

首先查看当前活动会话：

sql复制SHOW FULL PROCESSLIST;

发现有几个长期运行的查询，其中ID为8732的会话已经执行了超过600秒：

code复制I