【面试题001】生产环境中如何排查MySQL CPU占用率高达100%？

1.确认CPU高占用是否由MySQL进程引起

使用系统命令（如top、htop）确认是mysqlId进程导致CPU飙高，排除系统其他进程干扰。

• top -c ：-c 参数，显示完整命令行（可更清楚看到是 mysqld）；默认按 %CPU 排序，看到 CPU 占用最高的进程

  • 判断方法：看是否是 mysqld 占用了大部分 CPU（比如 80%+）；如果服务器是多核，CPU 总占用可以超过 100%（比如 300% 表示用了 3 核）；如果不是 mysqld 占用高，而是其他进程如 java、python，说明你要调查的目标不是 MySQL

• htop ：需要提前安装。图形界面更直观，支持筛选进程、查看 CPU 核心利用情况，可以按 F6 选择排序字段（比如按 %CPU 排序）

2.查看MySQL当前线程和执行的SQL

执行 SHOW FULL PROCESSLIST;，观察当前正在执行的SQL，排查是否有大量复杂或慢查询、锁等待、阻塞线程。

• 重点关注 Command 为 Query、Time 较长(大于10s)、State 为 Sending data 或 Locked 的线程，判断是否存在慢查询或阻塞线程。
  

3.分析慢查询日志和一般查询日志

检查是否开启慢查询日志，定位执行时间长、消耗资源高的SQL语句，针对这些SQL进行优化。

• 慢查询日志：慢查询日志 MySQL提供的一种日志机制，用于记录执行时间超过指定阈值的SQL语句。
• 登录MySQL查看是否开启慢查询：SHOW VARIABLES LIKE '%slow_query_log%';
  
• 如果没有开启，可以通过以下语句临时启用（重启失效）：SET GLOBAL slow_query_log = 'ON';

4.查看SQL执行计划

针对高耗CPU的SQL语句，使用EXPLAIN分析执行计划，判断是否存在全表扫描、缺索引、临时表等影响性能的因素。

• EXPLAIN 是 MySQL 提供的命令，用于查看 SQL 的执行计划，包括是否使用索引、扫描方式、连接方式等，可以评估该 SQL 的性能。
• 基本语法：EXPLAIN SELECT * FROM your_table WHERE your_column = 'xxx';执行后会得到类似这样的输出：
  
• 重点关注 type 字段是否为 ALL（全表扫描）、Extra 是否包含 Using filesort 或 Using temporary。如果存在这些问题，我会通过添加合适索引、调整 SQL 写法（如避免 SELECT *、避免 %模糊匹配）、优化字段类型等手段提升性能。
  

5.检查锁和事务情况

用SHOW ENGINE INNODB STATUS\G查看InnoDB锁信息，确认是否存在锁等待或死锁导致线程阻塞和CPU负载。

• 这是 MySQL 提供的 InnoDB 存储引擎状态查看命令 ，输出内容很多，重点关注：
  • 死锁信息（LATEST DETECTED DEADLOCK）
  • 当前锁等待（TRANSACTIONS）
  • 阻塞线程信息
• 登录MySQL后执行该命令。特别关注 LATEST DETECTED DEADLOCK（死锁）、TRANSACTIONS（是否存在等待锁的事务）、SEMAPHORES（是否存在严重锁竞争）。如果发现问题，结合业务逻辑优化事务提交时间、索引策略、表结构等，缓解锁争用带来的高 CPU 和延迟问题。

6.观察系统整体资源状况 ​

通过vmstat、iostat、sar等（ Linux/Unix 系统工具，在 Windows 系统中默认是无法直接使用的）系统工具检查磁盘IO、内存、网络等是否有瓶颈，避免CPU因等待IO造成的假高负载。

• vmstat ------ 综合查看 CPU、内存、IO 状况：vmstat 1 5 每隔 1 秒采样一次，总共采样 5 次。
• sar ------ 历史性能趋势分析（CPU、网络、磁盘）
  • sar -u 1 5 # 查看CPU状态
  • sar -r 1 5 # 查看内存
  • sar -n DEV 1 5 # 查看网络流量
• 使用vmstat、iostat 和 sar 分析 CPU 占用是否因 IO 等待引起（即假高负载）。特别关注 wa（等待IO）指标是否高于 20%，以及磁盘 %util 是否超过 80%、await 是否较高。如果发现 IO 或内存瓶颈，进一步检查磁盘压力来源，比如慢查询、大量日志写入，或者缓存失效引发的大量磁盘访问。