📌今日关键词：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看全局趋势
vmstat 1 10
每隔1秒采样10次，观察趋势。
r列（运行队列）：大于CPU核数，CPU已经不够用了。
b列（阻塞队列）：大于0说明进程在等IO。
swap列的si、so：非0说明内存不够，在换入换出。
cs列（上下文切换）：突然飙升，检查连接数和锁。
vmstat讲究看趋势。单次值没意义，连续看几秒才准。
第三步：iostat确认IO瓶颈
iostat -x 1
%util接近100%，磁盘快打满了。
await远大于svctm，IO在排队了。
CPU 100%有时候是假象。wa高说明瓶颈在磁盘，CPU其实在等IO。这时候加CPU没用，得解决磁盘问题。
第四步：SHOW PROCESSLIST查数据库
系统层看完，如果锁定了mysqld，就该深入数据库了。
SHOW FULL PROCESSLIST;
这一步是DBA排查的核心。看三个东西：
连接数：正常几十到几百。突然飙到几千，就是连接风暴。连接风暴会触发大量上下文切换，sy直接飙高。
正在执行的SQL：State列显示Executing的，就是正在跑的SQL。有没有跑了很久的慢SQL？
锁等待：State显示Lock wait的，说明在等锁。大量Lock wait堆积，CPU全花在锁管理上了。
连接风暴是CPU高的常见原因。应用连接池配置不当，或者故障重试机制有问题，瞬间打进来几千个连接。
第五步：慢查询找元凶
-- 看当前执行时间最长的SQL
SELECT * FROM information_schema.processlist
WHERE command != 'Sleep'
ORDER BY time DESC LIMIT 10;
或者直接看慢查询日志：
tail -100 /var/log/mysql/slow.log
慢查询是CPU高的最大元凶。常见情况：
全表扫描：没走索引，几百万行全扫一遍。CPU一直在做行比较。
复杂排序：ORDER BY + GROUP BY组合，临时表放不下写磁盘。CPU和IO同时飙高。
子查询嵌套：优化器选错执行计划，嵌套循环跑了上亿次。
看Rows_examined字段。扫描行数远大于返回行数，就是索引没用对。
补充：InnoDB状态看锁竞争
SHOW ENGINE INNODB STATUS\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查锁竞争。
避坑清单
- 不要上来就重启：重启丢现场，后面找不到根因
- 先保存现场：top、vmstat、SHOW PROCESSLIST结果先存下来
- us/sy/wa要分清：us高是计算问题，sy高是连接/锁问题，wa高是磁盘问题
- 连接数要监控：连接风暴是CPU高的常见元凶
- 看Rows_examined：扫描行数远大于返回行数，索引有问题
- 热点行要警惕：库存扣减、余额变更是高频锁竞争场景
- Buffer pool hit rate要关注：低于99%说明内存不够
- 慢查询日志要开：没开慢查询日志，排查就是瞎猜
- 不要只看平均值：一条慢SQL就能把CPU打满
- 完善监控：出事后第一件事是完善监控，别第二次还是懵的
这些命令看着不多，但排一次完整的故障就全记住了。
下一篇我来讲，凌晨3点从库备份锁表怎么一步步把整个系统拖垮的。真实案例，比工具命令有用多了。
我是数据库小学妹，咱们下篇见 👋
