首先确认高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，查看正在执行的请求：

重点关注：

• 状态为Running或Sending data且时间较长的查询
• 大量处于Locked状态的语句，可能有锁等待
• 重复出现的相同SQL，可能是高频低效查询

更详细信息可用：

启用并分析慢查询日志

慢查询是CPU升高的常见原因。确保慢查询日志已开启：

然后重现高负载场景，用mysqldumpslow或pt-query-digest分析日志：

找出执行次数多、耗时长、扫描行数大的SQL重点优化。

检查索引和执行计划

对可疑SQL使用EXPLAIN分析执行计划：

关注点：

• 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，再优化索引或逻辑。定期巡检能避免问题积累。