干这行十几年，最怕半夜手机响。接起来一听，十有八九是MDF文件打不开了，或者LDF日志文件莫名其妙没了。那种心情，就像你辛辛苦苦攒了十年的照片，突然发现硬盘转不动了。数据库这玩意儿，平时安安静静躺在服务器里，一旦出事，那就是天塌下来的大事。今天不聊那些高大上的理论，就说说我这些年踩过的坑、试过的招，全是真金白银换来的实战经验。
先分清主次。MDF是主数据文件，你所有的表、存储过程、视图，全在这一个文件里。LDF是日志文件，记录每一次增删改查的操作轨迹。很多人一看到LDF丢了就慌，其实大可不必。MDF是命根子，LDF是备胎——重要，但没到缺了就不能活的程度。最怕的是MDF损坏，那才是真正的灾难。我见过一个客户，MDF文件0字节，当时差点没给他跪了。0字节意味着文件头没了，整个文件结构全废了，常规手段根本没法救。所以，拿到问题文件，第一件事不是急着修复，而是先复制一份出来，原文件千万别动，这是铁律。
说说最常见的情况：MDF完好，LDF丢失。这时候SQL Server默认是不让你附加的，会报错“日志文件丢失”。别慌，有个官方支持的招数，把数据库设为紧急模式，然后强制重建日志。具体操作不复杂，先停掉SQL服务，把MDF文件单独拷到安全位置，然后启动SQL Server，执行，再执行，重建日志。这三板斧下来，大部分情况都能把库捞回来。但有个前提，你MDF文件必须是完整的，哪怕脏数据都行。要是MDF本身就有物理损坏，这招就不灵了。
再讲讲MDF文件损坏的情况。这是硬骨头，得看损坏程度。轻微损坏，就是某些页面的校验值对不上，数据库还能启动，但查询会报错。这时候SQL Server自带的DBCC CHECKDB能派上用场，，注意括号里那个参数，意思是允许丢数据。很多DBA一看到“DATALOSS”就哆嗦，其实没那么吓人。它丢的一般是那些已经损坏、读不出来的数据页，剩下的都是好的。比起整个库报废，丢几个页面的数据，已经是捡了大便宜。我有个做电商的朋友，订单表坏了几页，丢了大概几百条订单数据，但整个库救回来了，他连喝了三杯酒压惊。
但如果是文件头损坏，或者文件被加密、被格式化，那就得上第三方工具了。市面上工具不少，但靠谱的不多。我试过好几款，有些号称能修复，结果扫了半天，出来一堆乱码，反而把现场搞得更乱。我的经验是，工具越便宜越要小心，那些免费的小软件，很可能在你原文件上做手脚，越修越坏。真正能用的，要么是ApexSQL Recover这种老牌商业工具，要么是专业的数据库恢复服务。不过说实话，工具只能处理逻辑损坏，物理损坏——比如磁盘坏道划伤了文件——工具基本无能为力，这时候只能找数据恢复公司，用开盘、镜像这类硬核手段。
有个场景很多人忽略：MDF和LDF都丢了，但备份是旧的。这时候怎么办？我的建议是，先恢复最近一次的完整备份，然后尝试追加事务日志备份。但如果你没有日志备份，或者日志备份链断了，那从备份恢复之后，数据会缺失一段时间。这时候别急着上线，先和业务方沟通，确认缺失数据的影响范围。我有一次就是，客户为了图省事，没做日志备份，结果恢复完丢了两小时数据，财务那边直接爆了。所以啊，备份策略这东西，平时看着烦，关键时刻能救命。
再说一个冷门但实用的技巧：当MDF和LDF都存在，但附加时报错，说文件版本不兼容，或者文件大小和日志大小对不上。这种情况通常是之前做过收缩操作，或者数据库升级过。你可以试试用这个系统存储过程，它允许你只附加MDF，然后自动重建日志。这个命令在SQL Server 2005到2019都有效，但要注意，它要求MDF文件必须是干净的，不能有未提交的事务。如果有未提交事务，重建日志的时候会自动回滚，数据不会丢，但性能会受影响。
说点心理层面的。遇到数据库故障，最忌讳的是病急乱投医。我见过太多人，一着急就乱执行命令，把能用的库折腾成不能用的。正确的姿势是：先评估，后动手。评估包括——文件损坏程度如何？有没有备份？备份完整性如何？业务能容忍多少数据丢失？这四个问题想清楚了，再决定用什么方案。如果拿不准，宁可先不碰文件，找专业人士看一眼。要知道，数据库恢复这行，一次错误的尝试，可能让本来能救的数据彻底变成一堆乱码。修复完成后，别急着把库挂回去，先做一次全库校验，跑一遍，确认没有错误了，再切正式环境。
说到底，MDF和LDF的恢复，拼的不是技术，是冷静。文件丢了能找回来，数据坏了能修，但如果你慌了神，乱操作一气，那就真的回天乏术了。把这篇文章收藏起来，下次遇到问题，先深呼吸，然后按照上面的思路一步步来。数据库这行，见过的坑越多，胆子反而越小，但处理起来也越稳。
