MySQL CPU 占用过高，核心不是“压测一下再调”，而是快速区分是外部压力驱动还是内部执行低效。先看现象，再查根源，最后动手优化——跳过这三步，盲目调参或加索引反而可能让问题更隐蔽。
确认是不是 mysqld 真正在吃 CPU
别一上来就进数据库。先在系统层确认：
运行 top 或 htop，按 P（按 CPU 排序），找到mysqld进程；如果它长期 >80%，继续往下查 运行 ps -mp
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 都可能引发连锁等待
