首先确认高CPU是否由MySQL引起，通过top观察mysqld进程；再用SHOW PROCESSLIST查看运行中的SQL，关注长时间运行或锁定状态的查询；开启慢查询日志并设置阈值，利用mysqldumpslow或pt-query-digest分析高频、耗时SQL；对问题SQL执行EXPLAIN检查全表扫描、缺失索引或临时排序等问题，针对性添加索引或重写；借助sys.schema视图监控语句性能；最后评估innodb_buffer_pool_size、max_connections等参数合理性，避免配置不当导致资源争用。
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
检查MySQL配置合理性
某些配置不当也会加重CPU负担：
- innodb_buffer_pool_size过小，导致频繁磁盘读
- query_cache_type开启但命中率低，反而增加开销（MySQL 8.0已移除）
- max_connections过高，引发过多并发线程竞争
结合服务器内存和负载调整参数。
基本上就这些。关键是从活跃会话入手，结合慢日志和执行计划，找到“吃”CPU的SQL，再优化索引或逻辑。定期巡检能避免问题积累。
