数据库崩了，这种事情早晚会碰上。我做了十几年数据恢复，见过太多人盯着屏幕上的错误提示手足无措。MSSQL报错“数据库可疑”，或者干脆连不上，那一刻的心跳加速，只有经历过的人才懂。别慌，今天我把压箱底的实战经验掏出来，从诊断到修复，一步步说清楚。
第一步，先搞清楚问题有多严重。打开SQL Server Management Studio，看看数据库状态。如果显示“可疑”，先别急着点任何修复按钮。右键属性，把数据库改成单用户模式，然后执行DBCC CHECKDB命令。这条命令会扫描整个数据库，告诉你哪些地方坏了——是索引、页，还是系统表。我见过最坑的情况是，有人一上来就运行修复命令，结果把好的数据也搞乱了。记住，先诊断，再动手。
拿到检查结果后，看错误级别。如果只是索引或非聚集索引坏了，那简单，直接重建索引就行。命令是DBCC DBREINDEX。但如果是数据页或系统表出问题，就得用DBCC CHECKDB带修复参数。这里有个关键点：修复级别分三种。REPAIRREBUILD只修复索引和页结构，不丢数据。REPAIRALLOWDATALOSS会删除损坏的行，能保住大部分数据。最极端的是REPAIRREBUILDWITHDATALOSS，这个基本是最后的手段。我一般建议先用REPAIRREBUILD，不行再升级。
实战中，最棘手的是数据库处于“恢复挂起”状态。这种情况通常是日志文件损坏或磁盘空间满了。先检查磁盘空间，如果满了，清理出来重启服务。如果还是不行，就得动日志文件。先把数据库设置为紧急模式，用ALTER DATABASE SET EMERGENCY。然后运行DBCC CHECKDB带REPAIRALLOWDATALOSS。注意，这一步会丢失部分数据，但总比整个库报废强。我处理过一个案例，客户400G的数据库，用这个方法救回来380G，虽然丢了20G的历史记录，但核心业务保住了。
如果连紧急模式都进不去，那就得硬上。创建同名数据库，然后把坏库的.mdf文件覆盖进去。接着运行DBCC CHECKDB，系统会尝试从损坏的文件里读取可用数据。这个方法成功率不高，但值得一试。关键是要先备份好原文件，别弄巧成拙。我见过有人直接删掉坏文件重建，结果连恢复的机会都没了。记住，永远保留原始文件副本。
除了手动修复，商业工具也能救急。市面上有几款MSSQL修复软件，比如Stellar Repair for MS SQL、Kernel for SQL Database。这些工具能自动扫描坏文件，提取可读数据。但别指望它们万能。我测试过几款，对于轻度损坏，比如索引错误，它们表现不错。但遇到系统表损坏或文件头损坏，基本没戏。而且价格不菲，一套几千块。所以我的建议是：先用免费命令试，不行再考虑商业工具，别一上来就花钱买软件。
修复完成后，别急着上线。先做完整性检查，运行DBCC CHECKDB确保没问题。然后测试关键业务查询，看看数据是否一致。我遇到最坑的是，修复后数据能读，但某个字段的值全乱了。比如客户表里的电话号码全部变成乱码，这种问题命令检测不出来，只能通过业务测试发现。所以修复完成后，一定要让业务部门参与验证，别自己拍脑袋认为没问题。
说点预防的事。数据库损坏最常见的原因是突然断电、磁盘坏道、系统崩溃。所以装个UPS不间断电源，定期做磁盘检查，比啥修复技巧都管用。还有，备份策略要到位。全量备份每天一次，日志备份每15分钟一次。这样就算崩了，最多丢15分钟的数据。我见过最惨的案例，一家公司半年没做备份，数据库崩了直接回到解放前。修复技术再牛，也比不上一个靠谱的备份。
数据库修复这事，七分靠技术，三分靠运气。但掌握这些实战技巧，至少能让你在出事时不慌。记住，先诊断、再修复、再验证。别贪快，别盲目用高级参数。搞数据恢复，稳字当头。如果实在搞不定，找专业的数据恢复公司，别硬扛。毕竟数据无价，时间更贵。
