CPU飙到100%怎么排查？DBA手把手教你从top到慢查询定位根因

📌今日关键词：CPU 100%、top、vmstat、iostat、SHOW PROCESSLIST、慢查询、InnoDB、锁竞争、连接风暴

大家好，我是数据库小学妹 👋

凌晨收到CPU 100%告警，是不是很慌？

之前有朋友问我：CPU飙满了，怎么判断是不是数据库的锅？

说实话，我第一次遇到完全懵了。只知道重启数据库。后来发现重启不管用，半小时后CPU又飙满了。

今天就聊聊，DBA遇到CPU 100%该怎么排查。

先搞清楚CPU在忙什么

CPU占满不是问题的终点。us、sy、wa才是关键线索。

us（用户态）：应用在跑计算。us高，通常是SQL在做大量计算或排序。

sy（内核态）：系统在忙。sy高，通常是连接风暴或锁竞争。

wa（IO等待）：CPU在等磁盘。wa高，说明磁盘是瓶颈。

load average：top第一行有三个数。一分钟、五分钟、十五分钟的平均负载。负载接近或超过CPU核数，说明压力很大。

这几个指标看完，CPU 100%的原因基本就有方向了。

第一步：top看谁在吃CPU

top-c

看到CPU 100%，先看哪个进程在吃资源。

如果是mysqld，数据库本身有压力。继续往下排查。

如果是别的进程，比如Java应用，CPU高可能跟数据库无关。到这步就可以转给开发了。

关键看两个东西：哪个进程吃CPU，吃了多少。mysqld独占80%以上，基本锁定是数据库问题。

第二步：vmstat看全局趋势

vmstat110

每隔1秒采样10次，观察趋势。

r列（运行队列）：大于CPU核数，CPU已经不够用了。

b列（阻塞队列）：大于0说明进程在等IO。

swap列的si、so：非0说明内存不够，在换入换出。

cs列（上下文切换）：突然飙升，检查连接数和锁。

vmstat讲究看趋势。单次值没意义，连续看几秒才准。

第三步：iostat确认IO瓶颈

iostat-x1

%util接近100%，磁盘快打满了。

await远大于svctm，IO在排队了。

CPU 100%有时候是假象。wa高说明瓶颈在磁盘，CPU其实在等IO。这时候加CPU没用，得解决磁盘问题。

第四步：SHOW PROCESSLIST查数据库

系统层看完，如果锁定了mysqld，就该深入数据库了。

SHOWFULLPROCESSLIST;

这一步是DBA排查的核心。看三个东西：

连接数：正常几十到几百。突然飙到几千，就是连接风暴。连接风暴会触发大量上下文切换，sy直接飙高。

正在执行的SQL：State列显示Executing的，就是正在跑的SQL。有没有跑了很久的慢SQL？

锁等待：State显示Lock wait的，说明在等锁。大量Lock wait堆积，CPU全花在锁管理上了。

连接风暴是CPU高的常见原因。应用连接池配置不当，或者故障重试机制有问题，瞬间打进来几千个连接。

第五步：慢查询找元凶

-- 看当前执行时间最长的SQLSELECT*FROMinformation_schema.processlistWHEREcommand!='Sleep'ORDERBYtimeDESCLIMIT10;

或者直接看慢查询日志：

tail-100/var/log/mysql/slow.log

慢查询是CPU高的最大元凶。常见情况：

全表扫描：没走索引，几百万行全扫一遍。CPU一直在做行比较。

复杂排序：ORDER BY + GROUP BY组合，临时表放不下写磁盘。CPU和IO同时飙高。

子查询嵌套：优化器选错执行计划，嵌套循环跑了上亿次。

看Rows_examined字段。扫描行数远大于返回行数，就是索引没用对。

补充：InnoDB状态看锁竞争

SHOWENGINEINNODBSTATUS\G

重点看TRANSACTIONS部分。

如果有大量lock wait，说明热点行竞争严重。比如电商场景的库存扣减、账户余额变更，大量事务抢同一行。

InnoDB行锁虽然粒度小，但热点行场景下跟表锁没区别。CPU全花在锁管理上了。

再看BUFFER POOL部分。Buffer pool hit rate低于99%，说明内存不够，频繁从磁盘读数据。这也会加重CPU负担。

排查决策树

整个过程用决策树串起来：

用top找到吃CPU的进程。不是mysqld就转开发。

是mysqld就vmstat看sy是否高。sy高查连接数。

sy正常查wa。wa高查iostat看磁盘。

wa正常查us。us高查慢查询。

慢查询正常查SHOW PROCESSLIST。有Lock wait查锁竞争。

避坑清单

1. 不要上来就重启：重启丢现场，后面找不到根因
2. 先保存现场：top、vmstat、SHOW PROCESSLIST结果先存下来
3. us/sy/wa要分清：us高是计算问题，sy高是连接/锁问题，wa高是磁盘问题
4. 连接数要监控：连接风暴是CPU高的常见元凶
5. 看Rows_examined：扫描行数远大于返回行数，索引有问题
6. 热点行要警惕：库存扣减、余额变更是高频锁竞争场景
7. Buffer pool hit rate要关注：低于99%说明内存不够
8. 慢查询日志要开：没开慢查询日志，排查就是瞎猜
9. 不要只看平均值：一条慢SQL就能把CPU打满
10. 完善监控：出事后第一件事是完善监控，别第二次还是懵的

这些命令看着不多，但排一次完整的故障就全记住了。

下一篇我来讲，凌晨3点从库备份锁表怎么一步步把整个系统拖垮的。真实案例，比工具命令有用多了。

我是数据库小学妹，咱们下篇见 👋