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 "%x\n"
，后续可结合 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 STATUS\G，看TRANSACTIONS和LOCK WAIT部分；长事务、未提交更新、gap lock 都可能引发连锁等待
