MySQL CPU 占用过高需先定位瓶颈：查慢查询与执行计划、检查索引有效性与冗余、排查连接异常、核对配置与硬件匹配度，优先优化SQL和索引。
MySQL CPU 占用过高，核心思路是先定位瓶颈来源，再针对性优化——不是盲目调参，而是看慢查询、索引缺失、连接异常、硬件或配置不匹配等真实诱因。
查慢查询和执行计划
高 CPU 往往源于低效 SQL 频繁执行。开启慢查询日志（slow_query_log=ON），设置合理阈值（如 long_query_time=1），定期分析 slow.log 或用 pt-query-digest 工具汇总。
- 重点看 rows_examined 远大于 rows_sent 的语句，说明扫描行数多、命中率低
- 对高频慢 SQL 执行 EXPLAIN，检查是否走了索引、是否出现 Using filesort / Using temporary
- 特别关注 SELECT *、未加 LIMIT 的分页查询、WHERE 条件含函数（如 WHERE DATE(create_time) = '2024-01-01'）
检查索引有效性与冗余
缺少合适索引会导致全表扫描；索引过多或重复则增加写入开销和优化器决策负担，间接抬高 CPU。
- 用 SELECT * FROM sys.schema_unused_indexes 查未被使用的索引（需启用 performance_schema）
- 用 SELECT * FROM sys.schema_index_statistics 看各索引的读写频次
- 联合索引要符合最左前缀原则，避免在区分度低的字段（如 status、is_deleted）上单独建索引
排查连接与会话异常
大量空闲连接、长事务、锁等待、Sleep 状态堆积，都会让线程持续占用 CPU 资源。
- 执行 SHOW PROCESSLIST，关注 State 列：Sending data、Sorting result、Locked、Copying to tmp table 是常见高 CPU 状态
- 检查 innodb_trx、innodb_lock_waits 表，确认是否存在长时间未提交事务或死锁链
- 设置 wait_timeout 和 interactive_timeout（如 300 秒），避免应用不释放连接
核对配置与硬件匹配度
不当的 MySQL 配置可能让 CPU 成为瓶颈放大器，尤其在内存充足但缓冲区设得太小、并发线程数远超物理核心时。
- innodb_buffer_pool_size 建议设为物理内存的 50%–75%，过小导致频繁磁盘读，CPU 空转等 IO
- innodb_thread_concurrency 不建议设为 0（默认），高并发下可设为 CPU 核数 × 2，避免线程争抢过度
- 检查是否启用了 query_cache（MySQL 8.0 已移除），旧版本中它在高写入场景下反而引发严重锁竞争
定位清楚后，优先修复 SQL 和索引，再调整配置，最后考虑升级硬件或拆分架构。多数情况下，一个没走索引的 COUNT(*) 或 JOIN 就能吃满 CPU，而不是数据库本身扛不住。
