这事儿我估计搞数据库的人十有八九都遇到过：登录 SQL Server，一看数据库状态，赫然写着“正在恢复”。心里咯噔一下，第一反应往往是“完了，数据会不会丢”。别慌，这其实是个常见现象，有时甚至是个好信号。但怎么处理，得看具体情况。
先说说“正在恢复”到底是啥。SQL Server 在启动时，或者数据库从故障中重启后，会自动检查事务日志。如果发现有不完整的事务——比如系统崩溃时正在写入的数据——就会自动执行前滚或回滚操作。这个过程叫恢复，目的是保证数据一致性。就像写文章写到一半电脑死机，重启后 Word 会问你要不要恢复未保存的内容，逻辑上是一样的。只不过数据库的恢复机制复杂得多，涉及事务日志、检查点、数据页完整性校验等底层技术。大多数情况下，这个过程是自动的，几秒到几分钟就能完成。但如果卡住了，或者反复进入恢复状态，那就得动点真格的了。
最怕的是长时间卡在“正在恢复”，比如超过半小时甚至几小时。这时候先别急着重装数据库，得看看日志。用 SQL Server Management Studio 打开错误日志，或者直接在 Windows 事件查看器里查找错误代码。常见原因包括：磁盘空间满、事务日志过大、文件损坏或系统资源不足。比如有一次帮朋友处理案例，他的数据库卡住是因为日志文件撑到 100 多 GB，而 C 盘只剩几百 MB。恢复过程需要写临时数据，磁盘满了就只能干瞪眼。解决办法其实很简单：清理磁盘空间，或者把日志文件挪到其他盘。如果空间够，但恢复仍然慢，可能是日志文件太大，恢复时需要重做大量事务。这时可以尝试用 强制回滚，但要注意，这会中断所有连接，生产环境要慎重。
还有一种情况是恢复过程中报错，比如提示“无法恢复数据库，因为日志文件损坏”。这时就得靠备份了。如果有完整的全量备份和日志备份，可以手动恢复：先用 恢复全量，再依次恢复每个日志备份，最后用 完成。这个过程像搭积木，每一步都要对应正确的时间点。如果没有日志备份，只有全量备份，那只能恢复到备份时间点，之后的数据会丢失。这就是为什么 DBA 天天念叨“备份要全，日志要勤”。别等出事了才后悔没做日志备份。
如果连备份都没有，或者备份文件也坏了，就只能考虑更激进的办法。比如用 检查数据文件是否损坏。如果只是索引损坏，可能还能修复；如果是数据页损坏，就得看能否从错误日志里找到具体的页面号，然后用 之类的命令修复。但说实话，这招风险极高，非专业人士千万别尝试。我有个朋友曾用网上的脚本强行修复，结果数据乱了，业务停了三天，最后只能花钱请微软技术支持才搞定。所以，遇到这种极端情况，最靠谱的办法是联系厂商或专业的数据恢复公司，别自己瞎折腾。
再说个容易被忽略的点：系统资源不足也会导致恢复卡住。比如 CPU 飙到 100%、内存不够，或者磁盘 I/O 瓶颈。恢复过程是单线程的，对 CPU 和内存要求不高，但对磁盘读写速度要求很高。如果数据库文件放在机械硬盘上，而事务日志又很大，恢复速度可能慢到让人怀疑人生。这时可以把数据库文件迁移到 SSD，或者增加内存缓存。另外，别忘了检查 SQL Server 的最大内存设置。如果设置得太小，恢复时内存不够，系统会频繁换页，性能直线下降。通常建议给 SQL Server 预留物理内存的 70% 左右，但具体要结合服务器负载来决定。
还有一种情况是数据库本身没问题，却被其他进程锁住了。比如后台脚本在跑，或者有人在执行长时间查询，导致恢复进程无法获取锁。这时可以用 或者 查看哪些会话在占用资源。找到阻塞源头后，用 命令终止那个会话。但要注意，杀掉会话可能会中断正在执行的事务，导致数据不一致，所以最好在业务低峰期操作，或先跟团队沟通。我曾遇到最奇葩的一次，是定时任务在凌晨跑数据清洗，结果和恢复进程撞上，导致数据库卡了一整夜。后来把定时任务改为错峰执行，问题就解决了。
说个保命技巧：定期做完整备份和日志备份，并把备份文件存到不同地点。别信什么“数据库很稳定，不会出问题”的鬼话。我见过太多人因为偷懒不做备份，结果数据库崩了，数据全丢，老板直接让走人。另外，遇到“正在恢复”时，先别急着操作，先查看错误日志，分析原因。如果只是正常恢复，等几分钟就好；如果卡住，再按上面的步骤排查。实在搞不定，就找专业人士帮忙。记住，数据库恢复不是炫技的地方，安全第一，数据至上。
