MySQL出现CPU占用过高时,通常和慢查询、锁竞争、配置不合理或并发过大有关。排查需要从系统层到数据库层逐步分析,定位根源。
查看系统级CPU使用情况
先确认是否是MySQL进程导致的高CPU:
使用top或htop 按P键按CPU排序,观察mysql进程(mysqld)的CPU占用率 若mysqld占比较高,基本可确定问题出在MySQL内部检查MySQL当前运行的SQL
连接到MySQL,查看正在执行的请求:
SHOW PROCESSLIST;重点关注:
状态为Running或Sending data且时间较长的查询 大量处于Locked状态的语句,可能有锁等待 重复出现的相同SQL,可能是高频低效查询更详细信息可用:
SHOW FULL PROCESSLIST;启用并分析慢查询日志
慢查询是CPU升高的常见原因。确保慢查询日志已开启:
SET GLOBAL slow_query_log = 'ON';SET GLOBAL long_query_time = 1;
SET GLOBAL log_output = 'FILE';
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
然后重现高负载场景,用mysqldumpslow或pt-query-digest分析日志:
mysqldumpslow -s c -t 10 /var/log/mysql/slow.log找出执行次数多、耗时长、扫描行数大的SQL重点优化。
检查索引和执行计划
对可疑SQL使用EXPLAIN分析执行计划:
EXPLAIN SELECT * FROM orders WHERE user_id = 123;关注点:
type是否为ALL(全表扫描) key是否为NULL(未走索引) rows是否过大 Extra是否有Using filesort或Using temporary根据结果添加索引或重写SQL。
监控系统性能指标
使用工具辅助判断:
innotop:实时查看MySQL线程、锁、事务等 performance_schema:启用后可查SQL执行统计 sys schema:提供更易读的性能视图,如host_summary_by_statement_latency SELECT * FROM sys.statement_analysis ORDER BY avg_latency DESC LIMIT 5;检查MySQL配置合理性
某些配置不当也会加重CPU负担:
innodb_buffer_pool_size过小,导致频繁磁盘读 query_cache_type开启但命中率低,反而增加开销(MySQL 8.0已移除) max_connections过高,引发过多并发线程竞争结合服务器内存和负载调整参数。
基本上就这些。关键是从活跃会话入手,结合慢日志和执行计划,找到“吃”CPU的SQL,再优化索引或逻辑。定期巡检能避免问题积累。
