服务器数据库突发卡死不用慌 手把手教你快速排查修复全流程

你有没有碰到过凌晨三点被告警电话炸醒的情况？爬起来一看监控，业务接口全报错，数据库直接卡死动都动不了，老板的夺命消息紧跟着就弹过来，整个人瞬间困意全没？我早年做运维的时候每周都能碰个两三次，踩的坑多了也摸出了一套标准化的修复流程，基本10分钟就能把业务拉回来。

先搞懂数据库卡死的常见诱因

说白了数据库卡死和你手机卡顿是一个逻辑，要么是被某个占着资源不释放的进程堵死了，要么是同时跑的请求太多超出了负载上限，找对诱因修复起来快得很。

锁冲突占了八成以上的卡死场景

这个就像你去奶茶店点单，前面有个人占着收银台纠结半小时不下单，后面所有人都堵着走不动。数据库里的行锁、表锁被长事务占着不释放，新的读写请求全卡在等待队列里，要不了半分钟整个库就动不了了。

只要还能连上数据库，先执行这条命令找异常进程：

``` show processlist where State like '%lock%'; ```

找到State列显示Waiting for table metadata lock的长事务，直接记ID执行kill 进程ID，一般杀完个两三秒锁就释放了，业务就能自动恢复。

资源打满是第二高发的卡死原因

就像你手机开了几十个后台APP没关，连微信都刷不动。要是业务上线了没加索引的SQL，全表扫描一跑，瞬间就能把CPU、内存干到100%，所有请求都得不到响应。

先在服务器层用top命令看mysqld的占用，要是CPU占比超过90%，直接进数据库看慢查询列表，碰到执行时间超过10秒的全表扫描查询先kill掉，资源使用率秒降，后续再给对应字段加索引就行。

不同卡死状态的应急修复操作

碰到卡死别先忙着查原因，优先保业务才是正经事，真等你查出来根因业务都断了半小时，老板都得给你发离职预警。

完全卡死优先救业务

要是连数据库都登不上，ssh连服务器都卡，别傻愣着排查了，直接重启才是最快的方案。物理机直接执行systemctl restart mysqld，云数据库就点控制台的重启按钮，别用kill -9强制杀进程，容易搞坏数据文件得不偿失。一般重启一分钟内就能恢复业务，等业务跑起来了再慢慢翻日志找根因。

半卡死状态做无损修复

要是还能正常登数据库，就不用搞重启那套，先清完锁进程再清空闲连接就行，执行这条命令看当前业务连接数：

``` select count() from information_schema.processlist where user='你的业务用户名'; ```

要是连接数已经达到配置的上限，就把空闲超过300秒的连接批量kill掉，给新请求腾位置，全程不会影响正在执行的正常业务。

修复完别忘了做这几件事兜底

很多人修完就把这事儿抛到脑后了，下次碰到一样的问题还得慌。你得把这次查到的慢查询全优化了，该加索引加索引，该改业务逻辑改业务逻辑。一定要给数据库加锁等待超时、最大连接数的兜底配置，比如把innodb_lock_wait_timeout设成5秒，别让一个事务锁占个几分钟。

再给监控加个告警规则，CPU超过70%、锁等待超过10个就发消息通知，别等全卡死了才后知后觉。这事儿吧，多踩两次坑就熟了，平时多模拟两次卡死应急演练，真出事儿了手都不会抖。