MySQL CPU 100%问题排查与解决

作为后端开发者，你是否遇到过这样的场景：系统运行良好，内存占用正常，但MySQL的CPU却突然飙升到100%，导致整个应用响应缓慢甚至宕机？今天，我们就来聊聊如何快速定位和解决这个棘手的问题。

问题症状

当MySQL出现CPU 100%的情况时，通常会伴随以下现象：

• 数据库响应变慢，查询超时
• 应用接口响应时间显著增加
• 用户体验急剧下降
• 但内存占用却并不高

这种情况往往让人摸不着头脑，因为从监控面板上看，似乎只有CPU这一项指标异常。

根本原因

经过大量实战经验总结，MySQL CPU被打满的主要原因包括：

1. 循环调用数据库 代码中存在循环体，每次循环都执行数据库查询，导致短时间内产生大量SQL请求。这种N+1查询问题在ORM框架中尤为常见。

2. 单次查询数据量过大 没有合理使用分页，一次性查询几万甚至几十万条数据，导致MySQL需要大量CPU资源进行数据扫描和处理。

3. 缺少索引或索引失效 查询条件没有命中索引，导致全表扫描，消耗大量CPU资源。

排查思路

第一步：进入MySQL命令行

mysql -u root -p

第二步：执行 SHOW PROCESSLIST

这是最关键的一步，通过这个命令可以看到当前MySQL正在执行的所有线程：

SHOW PROCESSLIST;

该命令会返回以下关键信息：

• ID：连接标识符，可用于后续操作
• USER：执行SQL的MySQL用户
• HOST：客户端主机名和端口，格式为 host_name:client_port
• DB：当前使用的数据库
• COMMAND：线程执行的命令类型
• TIME：线程处于当前状态的时间（秒）
• STATE：线程正在执行的操作状态
• INFO：正在执行的SQL语句（最重要！）

第三步：分析问题SQL

重点关注以下几点：

1. TIME列较大的记录：说明该SQL执行时间过长
2. 重复出现的SQL：说明存在高频调用
3. INFO列的SQL语句：分析是否存在全表扫描、缺少索引等问题

解决方案

应急处理

很多人第一反应是使用 KILL 命令终止问题SQL：

KILL [ID];

但实际上，这种方法往往无效！因为如果是代码逻辑问题，kill掉一个连接后，新的请求会立即产生新的连接，CPU依然会被打满。

根本解决

1. 定位代码位置 根据processlist中的SQL语句，在代码中搜索对应的查询逻辑，找到触发条件。

2. 关闭功能入口 先临时关闭导致问题的功能入口（如接口、定时任务等），确保系统恢复可用。这是止血的关键步骤。

3. 优化SQL和代码

• 将循环查询改为批量查询
• 添加合适的索引
• 使用分页限制查询数据量
• 优化查询条件，避免全表扫描
• 考虑使用缓存减少数据库压力

4. 测试验证 在测试环境充分验证优化效果后，再重新上线功能。

预防措施

1. 代码审查：重点关注循环中的数据库操作
2. 慢查询日志：定期分析慢查询，提前优化
3. 监控告警：设置CPU、慢查询等监控指标
4. 压力测试：上线前进行充分的性能测试

总结

MySQL CPU 100%问题看似棘手，但只要掌握正确的排查方法，就能快速定位根因。记住核心三步：SHOW PROCESSLIST定位问题SQL → 关闭功能入口止血 → 优化代码和SQL根治。预防永远大于治疗，良好的编码习惯和完善的监控体系，才是避免此类问题的根本之道。

你在实际工作中遇到过MySQL性能问题吗？欢迎在评论区分享你的经验！