SQL Server数据库坏了别慌，教你几句SQL语句轻松修复试试看

看到“数据库坏了”这几个字，很多人的第一反应可能就是头皮发麻，别急，这事儿没想象中那么可怕，很多所谓的“坏了”，其实只是一些小毛病，比如某个数据页有点问题，或者索引乱了套，在打电话给DBA或者准备跑路之前，不妨自己先试着用几句简单的SQL语句抢救一下,前提是你得有数据库的账号密码并且能连上去。

你得判断一下数据库到底“坏”在了哪里，SQL Server自己带了一个挺实用的命令，叫DBCC CHECKDB，这个命令就像是给数据库做全身检查的CT机，你可以在SQL Server Management Studio (SSMS) 里，新建一个查询窗口,然后输入下面这句：

DBCC CHECKDB('你的数据库名')

把‘你的数据库名’替换成你那个出问题的数据库的实际名字，回车执行后，SQL Server就会开始吭哧吭哧地检查这个数据库的逻辑和物理完整性，这个过程可能会花点时间,取决于你的数据库有多大。

检查完了之后，消息框里会给你出一份详细的“体检报告”，如果它最后一行显示“CHECKDB 在数据库 ‘你的数据库名’ 中发现 0 个分配错误和 0 个一致性错误”，那恭喜你，数据库大体上是健康的，问题可能出在别处，但如果它报了一堆红彤彤的错误信息，比如说什么“表ID为某某的对象中存在页错误”之类的,那就说明确实有地方出问题了。

这时候也别慌，我们有应对的办法，一种比较常见的情况是索引损坏，索引就像是书本的目录，目录乱了，书的内容还是好的，只是不好找，我们可以尝试先修复索引，针对单个表修复索引,可以用这个命令：

DBCC CHECKTABLE ('损坏的表名', REPAIR_REBUILD)

这个命令会尝试重新构建那个损坏的表的索引，而且这个过程通常是在线操作的，意味着在修复的时候，其他用户可能还能继续访问这个表（虽然不是绝对），影响相对较小，如果这个命令成功执行并且没再报错,那问题可能就解决了。

如果REPAIR_REBUILD这招不管用，或者DBCC CHECKDB报告的错误非常严重，涉及到更底层的数据结构，那就得考虑用更强大的修复方式了，SQL Server还提供了一个叫REPAIR_ALLOW_DATA_LOSS的选项，听这名字就知道，它允许数据丢失，是修复手段里的“大招”或者说是“最后一招”。

用法是这样的：

DBCC CHECKDB ('你的数据库名', REPAIR_ALLOW_DATA_LOSS)

这个命令会尝试修复所有发现的错误，但它的修复方式可能比较粗暴，它可能会把那些它认为已经损坏、无法挽救的数据页直接删除掉，然后把能救的数据重新组织起来，用这个命令是有风险的,可能会造成一部分数据永久丢失。

非常重要的一点是：在执行REPAIR_ALLOW_DATA_LOSS之前，只要还有一丝可能，一定要先备份数据库！ 哪怕你现在觉得这个数据库已经坏了，备份出来可能也是个坏的，但也最好备份一下，因为万一修复操作导致了更糟的情况，你连个“尸体”都没有，那就真的回天乏术了，有备份的话,至少还能找更专业的人士尝试从备份文件中提取数据。

数据库会处于一个奇怪的状态，比如显示“可疑”（Suspect），这时候你可能连正常访问都做不到，可以试试把数据库切换到紧急模式，然后再进行修复,步骤大致是这样的：

1. 先把数据库设置为单用户模式，防止别人捣乱：ALTER DATABASE 你的数据库名 SET SINGLE_USER WITH ROLLBACK IMMEDIATE
2. 然后设置为紧急模式：ALTER DATABASE 你的数据库名 SET EMERGENCY
3. 接着尝试修复：DBCC CHECKDB ('你的数据库名', REPAIR_ALLOW_DATA_LOSS)
4. 修复完成后，再把它恢复正常状态：ALTER DATABASE 你的数据库名 SET ONLINE 和 ALTER DATABASE 你的数据库名 SET MULTI_USER

这些方法都是从一些技术社区（比如CSDN、博客园、知乎上的DBA分享）里经常被提及的故障排查流程,它们对于处理一些常见的数据库一致性错误确实有效。

我必须得给你泼点冷水，这些SQL命令不是万能的。DBCC CHECKDB的修复功能，尤其是REPAIR_ALLOW_DATA_LOSS，应该被视为在没有备份的情况下的最后手段，它的首要任务是保证数据库结构的完整性，至于数据能救回来多少,有时候要看运气。

真正靠谱的、专业的做法是什么？是定期备份！定期做完整备份、差异备份和日志备份，如果你的数据库有定期备份，那么遇到这种“坏了”的情况，你最应该做的不是急着用这些修复命令,而是：

1. 先把当前损坏的数据库备份一下（如果还能备份的话）。
2. 然后还原最近一次完好的完整备份。
3. 再依次还原后续的差异备份和事务日志备份,尽可能将数据恢复到故障发生前的那个时刻。

这才是数据安全的正道，今天教你的这几句SQL语句，更像是家里备着的创可贴和感冒药，能处理一些小磕小碰，但真要是得了大病，还得去医院（找专业DBA）或者靠平时锻炼身体增强体质（完善的备份恢复策略）。

当你感觉SQL Server数据库坏了的时候，别慌，可以按照这个思路来：先DBCC CHECKDB检查，发现问题后尝试REPAIR_REBUILD修复索引，如果不行且情况紧急又没有备份，再谨慎使用REPAIR_ALLOW_DATA_LOSS这个终极手段，并且务必事先做好备份（哪怕是可能损坏的备份），这些方法能帮你解决一部分问题,但绝不能替代一个健全的备份策略。