如何排查MySQL数据库CPU占用过高的原因？-mysql教程-PHP中文网

mysql cpu占用过高90%以上通常不是sql本身慢，而是mysqld进程被误判为高负载，如sleep连接堆积、mysqldump子进程或连接池泄漏；需先通过top确认真实cpu消耗者，再结合threads_running与qps判断是否真高并发，并用performance_schema实时定位高开销sql及内存使用，同时检查tmp_table_size等参数是否失衡导致磁盘临时表。

如何排查mysql数据库cpu占用过高的原因？

MySQL CPU 占用过高，90% 以上不是 SQL 本身慢，而是 mysqld 进程被误判为“高负载”——比如大量 Sleep 连接堆积、mysqldump 子进程、或应用连接池未释放。先确认是不是 mysqld 真正在吃 CPU，再进数据库查。

看系统层：top 里到底谁在占 CPU

执行 top -b -n1 | grep mysqld，重点关注三列：

%CPU 持续 >80%，且 RES（物理内存）稳定 → 大概率是密集计算型查询，比如 GROUP BY、ORDER BY 或没走索引的 WHERE
RES 同步暴涨 → 可能是 tmp_table_size / sort_buffer_size 配得太小，强制落盘临时表，反复读写放大 CPU 开销
看到多个 mysqld 行（尤其带 dump、backup 字样）→ 定时脚本或运维操作在后台跑，不是业务 SQL 的锅

⚠️ 容易踩的坑：htop 默认不展开线程树，mysqld 的每个连接是一个独立线程；4 核机器上 50 个并发慢查询，top 显示单个 mysqld 进程 CPU 就可能飙到 400%（即 400%），别只盯着百分比数字。

查 MySQL 层：Threads_running 和 QPS 要一起看

单独看 SHOW FULL PROCESSLIST 容易漏掉关键信息。优先执行这两条：

SHOW GLOBAL STATUS LIKE 'Threads_running'; —— 当前真正干活的线程数。长期 >30 就危险
SHOW GLOBAL STATUS LIKE 'Questions'; 和 SHOW GLOBAL STATUS LIKE 'Uptime'; —— 算出真实 QPS：Questions / Uptime

如果 Threads_running 高但 QPS 很低，说明大量线程卡在某个环节（比如等锁、等磁盘 IO、排序内存不足）；如果两者同步飙升，才是真高并发压力。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

⚠️ 容易踩的坑：SHOW PROCESSLIST 里 State = Sending data 不代表正在发数据，MySQL 8.0+ 里它常表示“正在做聚合/排序”，本质是 CPU 密集型阶段。

定位高开销 SQL：别只盯慢日志，先看 performance_schema

慢日志是“事后记录”，而 performance_schema 是实时快照，更准更快：

查当前最耗 CPU 的 SQL（按执行时间）：
SELECT DIGEST_TEXT AS query, SCHEMA_NAME AS db, SUM_TIMER_WAIT/1e9 AS time_sec, SUM_ROWS_EXAMINED AS rows FROM performance_schema.events_statements_summary_by_digest WHERE SUM_TIMER_WAIT > 0 ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;
若发现某 SQL rows_examined 百万级，但只返回几行 → 基本确定缺索引或用了 LIKE '%xxx' 导致索引失效
检查是否启用了关键 instrument：SELECT * FROM performance_schema.setup_instruments WHERE NAME LIKE 'memory/sql/%' AND ENABLED = 'NO';，若 memory/sql/TABLE 是 NO，内存分析会漏掉临时表开销

⚠️ 容易踩的坑：MySQL 8.0 默认关闭部分 memory instruments，不手动开就看不到“哪个 SQL 创建了多少临时表”。

验证执行计划：EXPLAIN 不等于真相，要看实际扫描行数

EXPLAIN 显示 type=ref 很漂亮，但 rows 列写的是 100，实际执行扫了 10 万行？那是统计信息过期了。

执行 EXPLAIN FORMAT=JSON SELECT ...，重点看 filtered 字段：如果远低于 100%，说明优化器预估严重失准
立刻执行 ANALYZE TABLE table_name; 更新统计信息，再跑一次 EXPLAIN
对高频慢查询，补联合索引时注意最左前缀：比如 WHERE a = ? AND b > ? ORDER BY c，索引应建为 (a, b, c)，不是 (a, c, b)

复杂点在于：CPU 高往往不是单个问题，而是“慢查询 + 锁等待 + 临时表 + 统计失准”叠加。最容易被忽略的是——你 fix 掉一条慢 SQL 后，Threads_running 下降了，但 innodb_row_lock_time_avg 反而升高，说明锁竞争转移到了别的热点行上。