MySQL CPU 占用过高，核心思路是“先定位、再归因、后优化”。重点不是看整体CPU百分比，而是确认是不是 mysqld 进程本身 在消耗CPU，以及它正在执行什么操作。
确认是否 mysqld 导致 CPU 高
用
top或
htop查看进程级占用： 运行
top -c，关注
%CPU列，找到
mysqld对应的 PID 若非 mysqld（比如 Java 应用或 cron 任务），就不用深入 MySQL 层面 进一步聚焦：用
top -Hp [PID]查看 mysqld 内部哪些线程最忙（注意 TID）
查当前活跃 SQL 和执行状态
登录 MySQL，快速识别“正在干坏事”的查询：
执行SHOW FULL PROCESSLIST;，重点关注
State是
Sending data、
Copying to tmp table、
Sorting result或
Creating sort index的连接 过滤非空闲会话：
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND != 'Sleep' AND TIME > 2;对可疑 SQL 执行
KILL [ID]临时止损（生产环境慎用）
分析慢查询和执行计划
CPU 高往往源于低效 SQL，尤其是没走索引、大量排序/分组、子查询嵌套深的语句：
开启慢查询日志（slow_query_log = 1，
long_query_time = 2），重启后收集典型负载时段日志 用
EXPLAIN分析问题 SQL，重点看：
–
type是否为
ALL（全表扫描）
–
key是否用了索引
–
Extra是否含
Using filesort、
Using temporary常见诱因：
ORDER BY + LIMIT无覆盖索引、
GROUP BY字段未建索引、
IN (subquery)未转成
JOIN、
WHERE条件中对字段做函数运算（如
DATE(created_at)）
检查配置与资源瓶颈
有些高 CPU 并非 SQL 本身问题，而是配置不合理放大了开销：
tmp_table_size和
max_heap_table_size过小 → 导致频繁磁盘临时表（
Copying to tmp table on disk），建议设为 64M~256M（需匹配内存）
innodb_buffer_pool_size过小 → 缓存命中率低，反复读磁盘+解析页，CPU 被 IO 等待掩盖但实际在忙调度 连接数爆满（
Threads_connected接近
max_connections）→ 线程上下文切换开销剧增 锁争用严重：查
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;和
SHOW ENGINE INNODB STATUS;中的死锁片段
