干这行最怕半夜手机响。上周凌晨两点，老张电话打过来，声音都是抖的——他们公司财务系统突然连不上数据库，几百号人的工资单全卡在里头。我远程一看，SQL Server报错1813，典型的MDF文件损坏。这种事儿我一年能碰上几十回，但每次看到客户那种眼神，心里还是咯噔一下。
先说清楚MDF到底是个啥。它是SQL Server的主数据文件，你所有的表结构、索引、存储过程，还有那些比命还重要的业务数据，全躺在里头。这文件一旦出问题，轻则某个表打不开，重则整个数据库起不来。最要命的是，很多人平时压根没想过备份，等真出事儿了才抓瞎。
MDF损坏的原因，十有八九离不开这几样：突然断电、硬盘坏道、病毒攻击，还有那种手贱去改文件属性的。前阵子有个客户，IT小哥为了腾空间，直接把数据库文件从D盘剪切到E盘，剪到一半断电了，结果两个盘的文件全废了。这种操作我看着都心疼，但确实每天都有人踩坑。
真遇到MDF损坏，第一反应千万别是去下载那些来路不明的修复工具。我见过太多人病急乱投医，拿个破解版软件一通扫，结果把文件搞得更烂，连专业恢复公司都摇头。正确的做法是先停掉SQL服务，把MDF和LDF文件原样复制一份，存到安全的地方，然后再开始折腾。
接下来这招是基本功：用DBCC CHECKDB碰碰运气。在命令提示符里敲上这么一行，系统会尝试修复逻辑错误。这招对付那种“文件结构没坏，但内部数据对不上号”的情况特别好使。但注意，它解决不了物理损坏，而且跑起来极占资源，最好挑个没人用系统的时候操作。
如果DBCC搞不定，那就得上更硬核的玩法了——建个全新的数据库，然后用“允许数据丢失”的模式去附加损坏的MDF。SQL Server会强制把能读出来的数据都拽出来，虽然可能丢一部分，但总比全没了强。具体操作就是右键数据库，选“附加”，然后手动指定文件路径，在选项里勾上那个带警告的选项。
有一种情况特别坑：MDF文件明明在，但附加的时候报“文件已存在”或者“文件大小异常”。这种多半是文件头被写坏了，系统认不出它是个数据库文件。这时候可以试试用第三方工具直接扫描文件内容，像ApexSQL Recover、Stellar Repair for MS SQL这类专业软件，能绕过文件系统，直接从残留的数据页里提取信息。
说个我自己的经验：有次客户的MDF文件被勒索病毒加密了，后缀全变成.locky，常规手段全废。我是用备份恢复的，但备份也停在了三个月前。那三个月的数据全得靠手工补录，几个小姑娘加了两个礼拜班才弄完。所以各位，备份这东西真不是说着玩的，每天至少做一次差异备份，每个礼拜做一次全量备份，丢数据的代价远超那点存储成本。
修复完不等于万事大吉。把数据库救回来之后，第一件事就是跑一遍完整性检查，确认没有残留问题。然后看看错误日志，搞清楚到底为啥坏的——是硬盘快挂了，还是电源不稳，或者有人乱动文件。不找到根源，这毛病迟早还得犯。
说句掏心窝子的：MDF损坏这毛病，三分靠修复，七分靠预防。你花两小时配置好备份计划，可能一辈子都用不上，但真到用上的那天，你救的可不是数据库，是整个公司的命根子。那些觉得“备份太麻烦”的人，多半是没经历过半夜被电话吵醒的滋味。
