MySQL CPU飙高问题排查与优化实战

1. 问题现象与初步判断

上周五凌晨2点，值班手机突然响起刺耳的告警声——生产环境MySQL实例CPU使用率突破90%阈值。作为DBA，这种半夜告警最让人头疼。登录监控系统查看，发现CPU负载从凌晨1:30开始持续攀升，已经持续高位运行30分钟。

通过performance_schema快速检查活跃会话，发现大量处于"Sending data"状态的查询。这些查询有个共同特征：都访问了同一张5000万行的用户行为日志表。更反常的是，这些查询本应是低频的报表分析SQL，却在短时间内出现爆发式增长。

经验提示：当CPU高负载伴随大量"Sending data"状态会话时，90%的情况是出现了全表扫描或索引失效问题

2. 排查工具链与诊断步骤

2.1 实时诊断三板斧

1. show processlist
   第一手现场取证，重点关注：

   • Time列大于60秒的长事务
   • Command列出现"Query"以外的异常状态
   • Info列包含可疑SQL片段

   示例输出：

   sql复制Id     | User    | Host         | db       | Command | Time | State       | Info
   123456 | report  | 10.0.1.2:123 | analytics| Query   | 112  | Sending data| SELECT user_id FROM behavior_log WHERE ...
   

2. performance_schema深度分析
   启用events_statements_history_long表（需提前配置）：

   sql复制SELECT THREAD_ID, SQL_TEXT, ROWS_EXAMINED, ROWS_SENT 
   FROM performance_schema.events_statements_history_long
   WHERE ROWS_EXAMINED/ROWS_SENT > 1000
   ORDER BY ROWS_EXAMINED DESC LIMIT 10;
   

   这个查询能快