MySQL CPU占用过高时，应先用top确认是否mysqld进程导致，再通过SHOW PROCESSLIST和EXPLAIN定位低效SQL，最后优化索引、配置及避免函数运算等诱因。
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;中的死锁片段
