17370845950

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 都可能引发连锁等待