线上服务器CPU暴涨排查指南：从系统到MySQL层
在日常运维或开发工作中，线上服务器突然出现CPU高负载暴涨是高频突发问题。若不能快速定位根源，可能导致服务响应缓慢、甚至集群宕机。本文将从系统层面和MySQL应用层面拆解排查流程，并梳理常见诱因，帮你高效解决CPU暴涨问题。
1. 系统层面排查：先定位硬件与系统进程
当收到CPU高负载告警时，第一步需先从操作系统层排查，排除硬件资源瓶颈或异常进程占用的问题。核心通过3类命令定位关键信息，操作步骤如下：
-
查看高CPU占用进程
执行top命令，实时查看系统进程的CPU使用率、内存占用等数据。通过排序（按P键按CPU使用率降序），可快速定位是否有单个或多个进程（如异常脚本、资源泄漏的服务）占用过高CPU。
-
检查内存使用情况
内存不足可能导致系统频繁Swap，间接引发CPU负载升高。通过以下两个命令查看内存状态：free -g：以GB为单位显示内存总容量、已用、空闲及Swap分区情况，适合快速概览。free -m：以MB为单位显示，精度更高，可用于判断是否存在内存紧张问题。
-
排查磁盘IO是否异常
磁盘IO瓶颈（如读写速度慢、IO等待高）会导致进程阻塞，进而使CPU处于“等待IO”的高负载状态。需先安装系统监控工具，再查看IO情况：-
安装工具：
yum install -y sysstat（适用于CentOS/RHEL系统）。 -
查看IO状态：
iostat，重点关注以下核心指标，结合数值判断设备健康度与负载情况：%iowait：CPU 空闲且等待 IO 操作完成的时间百分比，理想值≤2%，可接受值≤5%，超出则说明 IO 等待对 CPU 影响较大。tps：每秒 IO 请求数（含读、写、合并请求），直接反映设备 IO 压力。机械硬盘通常≤100（≥150 为高负载），SSD 则可达到数千。kB_read/s：每秒读取数据量（吞吐量），单位为 KB。需对比设备标称带宽（如 SATA 机械盘约 100MB/s，即 102400KB/s），判断是否达到读取性能瓶颈。kB_wrtn/s：每秒写入数据量（吞吐量），单位为 KB。参考标准与kB_read/s一致，且需注意写入速度通常慢于读取速度，机械盘此差异更明显。
-
若需更详细 IO 分析（如定位慢 IO）可执行
iostat -x 1（-x显示扩展指标，1每秒刷新一次），重点关注额外扩展参数：%util：设备利用率（核心！≥90% 说明设备满负荷）；avgqu-sz：平均 IO 队列长度（理想 ≤2，>5 说明请求堆积）；await：平均每次 IO 请求等待时间（含队列等待+设备处理，单位 ms，机械盘通常 ≤20ms，>50ms 可能有问题）；svctm：设备实际处理每次 IO 的时间（单位 ms，反映设备本身速度）。
-
系统层面排查后，若未发现异常进程或硬件瓶颈，需进一步深入MySQL数据库层——作为业务核心组件，MySQL的异常往往是CPU暴涨的“隐形推手”。
2. MySQL层面排查：聚焦SQL与数据库状态
MySQL作为关系型数据库，其SQL执行效率、锁等待、流量峰值等问题，是导致CPU高负载的核心诱因。需按“实时进程→慢查询→锁状态→流量峰值”的顺序逐步排查：
2.1 第一步：查看MySQL实时执行进程
执行SQL命令 show processlist;，查看当前MySQL正在运行的所有连接进程。重点关注两类进程：
- 状态为“Running”且
Time（执行时间）过长的进程，判断是否有长耗时SQL占用CPU。 - 状态为“Locked”“Waiting for table metadata lock”等阻塞状态的进程，排查是否存在锁等待。
2.2 第二步：分析慢查询日志
慢查询（通常指执行时间超过long_query_time阈值的SQL）是导致MySQL CPU暴涨的最高频原因，需通过慢查询日志定位问题SQL：
-
先确认慢查询日志已开启（可通过
show variables like 'slow_query_log';查看），若未开启需临时或永久开启（修改my.cnf配置）。
-
查看慢查询日志内容，筛选“CPU高负载时段”内的所有慢查询，重点关注：
- 是否存在“全表扫描”SQL（如未加索引、索引失效的
SELECT *查询）。 - 是否存在复杂关联查询（如多表JOIN未优化、子查询嵌套过深）。
- 是否存在“全表扫描”SQL（如未加索引、索引失效的
-
对可疑慢查询执行
explain命令，分析SQL执行计划：查看是否使用索引（key列非NULL）、rows（预估扫描行数）是否过大，进而判断是否需要添加索引或重构SQL。
2.3 第三步：检查锁等待与流量峰值
- 锁等待排查：若
show processlist;中存在大量锁等待进程，需进一步通过show engine innodb status;查看InnoDB锁详情，定位持有锁的进程和SQL。长时间锁等待会导致大量请求阻塞，间接推高CPU负载，需通知研发团队修改业务逻辑（如优化事务粒度、避免长事务）。 - QPS/TPS峰值排查：通过监控工具（如Prometheus、Zabbix）或MySQL自带命令（
show global status like 'Questions%';计算QPS），查看CPU暴涨时段是否存在QPS/TPS突然暴涨。若流量远超日常峰值，需排查是否是正常业务高峰（如促销活动），还是恶意攻击（如SQL注入、高频请求轰炸），并针对性处理（如扩容、加限流策略）。
3. 常见导致CPU暴涨的原因总结
结合实际排查经验，CPU高负载的核心诱因可归纳为4类，其中“慢查询”占比最高，需重点关注：
| 诱因类型 | 具体表现与影响 |
|---|---|
| 慢查询 | 缺索引、全表扫描、复杂SQL导致MySQL计算耗时增加，直接占用大量CPU；占CPU暴涨诱因的60%以上。 |
| delete删除大量数据 | 一次性删除上万条甚至百万条数据时，delete操作本身会占用CPU，同时会触发InnoDB事务日志写入、行锁持有，导致其他请求锁等待，间接升高CPU负载。 |
| 业务并发高 | 促销、秒杀等场景下，QPS/TPS突增，超过服务器承载能力，导致CPU忙于处理请求队列，负载飙升。 |
| 存储故障 | 若服务器使用虚拟机或云存储，底层存储（如磁盘、存储阵列）故障会导致所有MySQL事务处于“IO等待”状态，系统CPU因“等待IO完成”而显示高负载（实际是假高负载，需排查存储硬件）。 |
排查思路总结
解决CPU暴涨问题的核心逻辑是“从底层到上层，逐步缩小范围”：
- 先通过系统命令（top、free、iostat）排除硬件或系统进程异常；
- 再深入MySQL层，通过
show processlist、慢查询日志、锁状态排查定位SQL或数据库配置问题； - 最后结合业务场景，判断是否是流量峰值或存储故障，针对性优化。
日常运维中，建议提前做好监控（如CPU、内存、MySQL慢查询告警），并定期优化慢查询、梳理业务峰值，从“事后排查”转向“事前预防”，减少CPU暴涨的突发风险。
