mysql CPU 过高需先区分外部压力或内部低效：系统层确认 mysqld 进程 CPU 占比，定位高耗 线程 并关联 SQL；再通过 QPS 与 CPU 曲线对比判断是流量激增还是慢查询主导；最后用 processlist、慢日志或 Performance Schema 定位问题 SQL，并依执行计划优化索引、排序、临时表及连接管理。
MySQL CPU 占用过高，核心不是“压测一下再调”，而是快速区分是 外部压力驱动 还是 内部执行低效。先看现象，再查根源，最后动手优化——跳过这三步，盲目调参或加索引反而可能让问题更隐蔽。
确认是不是 mysqld 真正在吃 CPU
别一上来就进 数据库。先在系统层确认：
- 运行 top 或 htop，按 P（按 CPU 排序），找到
mysqld进程；如果它长期 >80%，继续往下查 - 运行 ps -mp
-o Thread,tid,time | sort -rn ，看哪个线程（TID）占 CPU 最多 - 把高耗 TID 转成十六进制：printf “%xn”
，后续可结合 SHOW PROCESSLIST或performance_schema.threads关联 SQL
区分是 QPS 激增还是慢查询主导
CPU 高 ≠ SQL 写得差，也可能是流量真的太大：
- 查当前 QPS：
SHOW GLOBAL STATUS LIKE 'Questions';和SHOW GLOBAL STATUS LIKE 'Uptime';，算出平均每秒查询数 - 对比历史曲线：如果 CPU 曲线和 QPS 曲线高度同步上升，大概率是 并发请求 太多，需从应用层限流、加缓存（如 redis）、或读写分离入手
- 如果 CPU 飙高但 QPS 平稳甚至偏低，重点盯慢查询、锁等待、临时表、排序操作——这类问题往往一条 SQL 就能拖垮整实例
定位高消耗 SQL 的三种实用方式
不用等慢日志满，现场就能抓到“真凶”：
- show full processlist：直接看
State列，重点关注Sending data（数据传输中）、Copying to tmp table（建临时表）、Sorting result（排序）、Locked（锁住）的语句；Info列显示不全时，用select * FROM information_schema.PROCESSLIST WHERE INFO IS NOT NULL - 启用并检查 slow_query_log：在 my.cnf 中设
slow_query_log = 1、long_query_time = 1（单位秒），重启后分析日志；注意：即使long_query_time = 0也能记录所有查询，适合紧急排查 - 用 Performance Schema 实时追踪：开启相关消费者，例如：
UPdate performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%statements%';，然后查performance_schema.events_statements_summary_by_digest，按TOTAL_LATENCY或EXEC_COUNT排序找“高频 + 高耗时”语句
常见瓶颈点与对应优化动作
找到 SQL 后，别急着改代码。先看执行计划，再定策略：
- 全表扫描（type=ALL）：explain 显示没走索引？检查 where 条件字段是否缺失索引，或存在 隐式类型转换（如 varchar 字段传数字）、函数包裹（
WHERE DATE(create_time) = '2025-12-20'） - using filesort / Using temporary：order by 或 group by 没走索引？尝试为排序字段加联合索引，或减少 select *，只取必要字段
- 大量临时表：检查
tmp_table_size和max_heap_table_size是否过小；临时表转磁盘会极大拉高 CPU，适当调大（但别超过物理内存 20%） - 连接数爆炸：
SHOW STATUS LIKE 'Threads_connected';如果接近max_connections，说明连接没释放，要查应用是否漏关连接，或启用连接池（如 HikariCP） - InnoDB 锁竞争：运行
SHOW ENGINE INNODB STATUSG，看TRANSACTIONS和LOCK WaiT部分；长事务、未提交更新、gap lock 都可能引发连锁等待
