前两天，我朋友老张在微信上急得跳脚，说他们公司的数据库突然在管理工具里显示“正在恢复”，整个业务系统直接瘫痪了半小时。他当时脸都绿了，因为正好赶上财务对账，十几万的订单卡在半路。我一边安慰他，一边想起自己刚入行时也遇到过类似情况，那时候真是两眼一抹黑，只能对着屏幕干瞪眼。其实“正在恢复”这个提示看着吓人，但本质上就是数据库在自我修复或重新加载数据的过程中，系统给出的状态信号。就像手机重启时屏幕上那个转圈圈，你看着急，但内核正在干活。
那么，数据库为什么会突然进入这个状态呢？最常见的原因是非正常关机或系统崩溃。比如机房突然断电，或者运维手滑重启了服务器，数据库没来得及优雅关闭，内存里的脏数据还没写进磁盘。下次启动时，数据库就得靠事务日志来“复盘”：哪些数据已经提交但未落盘，需要补上；哪些事务写到一半就断了，需要回滚。这个过程就叫恢复。有些数据库（如 SQL Server）启动时会自动走一遍这个流程，耗时取决于日志文件大小和服务器性能。我见过最夸张的一次，一个 500 GB 的数据库恢复花了三个多小时，运维小哥直接在机房打地铺等。
还有一种情况是，数据库在做“时间点恢复”或“还原备份”时，把自己锁在恢复模式里。比如误删了一张表，赶紧从昨天的全备文件里还原，这时数据库会先加载备份文件，然后应用日志里的增量数据，一直追到指定的时间点。整个过程数据库对外显示“正在恢复”，实际上是在后台进行“前滚”。这时如果手贱去点“停止”或重启服务，就会雪上加霜，轻则恢复失败，重则数据文件直接损坏，连备份都救不回来。我有个同事就干过这事，结果花了三天从磁带机里扒旧数据，被领导骂到怀疑人生。
另外，硬件故障或磁盘 I/O 性能瓶颈也是“正在恢复”的隐形杀手。恢复时需要大量读写日志文件和数据库文件。如果磁盘是机械硬盘，或者 RAID 卡故障、存储连接线松动，数据库读日志读到一半卡住，就会一直卡在“恢复”状态，进度条纹丝不动。我遇到过一台老旧服务器，硬盘灯疯狂闪烁，但恢复页面就是不走。后来查出来是磁盘坏道导致日志读取超时。更坑的是，有些云厂商的虚拟磁盘，IOPS 被其他虚拟机抢光，恢复速度慢得像蜗牛爬。这时候急也没用，只能先排查存储层。
还有一个容易被忽略的原因：数据库在正常运行时，如果触发了“自动收缩”或“自动增长”这类操作，也可能短暂显示“正在恢复”。比如 SQL Server 设置了数据文件自动增长，但磁盘空间不足，扩展文件时失败，数据库会自动进入恢复模式尝试回滚。或者手贱执行了 ，数据库在整理碎片时也可能短暂锁住某些页面，导致工具界面显示异常。不过这种情况通常几秒到几分钟就结束，除非同时有大事务在跑，让恢复过程变成拉锯战。
遇到“正在恢复”时，第一件事不是重启，而是冷静下来查看日志。数据库的错误日志里通常会写明具体原因：是“恢复正在进行，进度百分比”，还是“等待日志读取超时”，或者“无法访问磁盘”。Windows 事件查看器或 Linux 的 syslog 里也能挖到线索。比如 SQL Server 的日志里出现 “The log scan number passed to log scan in database 'xxx' is not valid”，大概率是日志文件损坏，需要从备份恢复。这时盲目操作只会扩大损失。一般会先跑个 看一致性，但要注意该命令本身也会消耗资源，生产环境慎用。
如果确定是正常启动恢复，那只能等。但等也有技巧：可以监控 视图，查看具体的等待类型和恢复进度。比如在 SQL Server 中，查询 就能看到恢复的百分比。如果进度卡在 99% 半小时不动，多半是事务日志里有大事务需要回滚，或者磁盘 I/O 扛不住了。这时可以尝试减少并发，让数据库独占资源，比如停掉其他应用，或临时关闭杀毒软件对数据库目录的扫描。别小看杀毒软件，我见过它扫描日志文件时，恢复速度慢了五倍。
说个扎心的真相：很多“正在恢复”其实是运维习惯不佳埋下的雷。比如从不做定期备份检查，备份文件损坏却不知道；又比如事务日志文件不设上限，任其膨胀到几百 GB，恢复时自然慢得要死；再比如服务器内存不足，数据库频繁写盘，一崩溃恢复数据量就巨大。我认识一个 DBA，数据库每天凌晨 2 点自动备份，但备份脚本里没加 参数，结果备份文件一直有损坏，直到灾难恢复时才暴露。所以别光盯着“正在恢复”骂娘，平时多检查备份有效性、合理规划日志文件、做好监控告警，才是治本之道。数据库不会无缘无故罢工，它只是在帮你擦屁股而已。
