数据库表突然报错，查询卡死，备份恢复又发现昨天的数据全丢了——这种场景干运维的都懂，那一刻血压直接拉满。SQL Server也好，MySQL也罢，表损坏这事儿不挑日子，偏偏爱在月底结账、年终盘点的时候冒出来。你越急，它坏得越彻底。但说句实在话，大部分“表损坏”根本没到需要重装数据库的地步，核心就三步：诊断、备份、修复。顺序不能乱，乱了就是数据二次损伤。
第一步，别急着修，先搞清楚到底坏在哪。很多人一看到“Table is marked as crashed”或者“Database page checksum mismatch”就慌了神，直接上手跑修复命令。这跟发烧先吃抗生素一样，大概率是白忙活。正确的做法是先用系统自带的检查工具做诊断。SQL Server里用DBCC CHECKTABLE，MySQL里用CHECK TABLE，这两个命令能告诉你具体是索引坏了、数据页损坏，还是仅仅统计信息过期。诊断结果里会给出错误级别，从“警告”到“严重错误”分好几档，只有严重错误才需要走修复流程。要是只是警告级别，重建个索引或者更新统计信息就能解决，压根不用折腾大动作。
第二步，也是很多人最容易跳过的——做完整备份。你可能会想，表都坏了还备份什么？恰恰相反，正因为坏了，备份才更要谨慎。这里说的备份不是让你把损坏的表原样拷一份，而是把那些还能正常读出来的数据赶紧导出来。用SELECT INTO或者导出CSV，把没坏的行先保住。这一步至关重要，因为后续的修复操作本质上是在“赌”，赌数据库能自己把残页拼回来。万一修复过程把仅存的完整数据页也搞乱了，至少还有一份能用的底子。我见过太多人上来就跑REPAIR TABLE，结果原本只是索引坏了，修复完整个表都打不开，只能从旧备份里恢复，白白丢了几个小时的数据。
第三步，根据诊断结果选择修复手段，这里有个优先级。最轻的是“重建索引”，适用于索引页损坏但数据页完好的情况，DBCC DBREINDEX或者ALTER INDEX REBUILD就能搞定，速度快，风险低。中等的是“修复数据页”，SQL Server里用DBCC CHECKTABLE WITH REPAIRALLOWDATALOSS，MySQL里用REPAIR TABLE，这类命令会把损坏的数据页标记出来，能救的救，救不了的直接丢弃。听起来吓人，但实际操作中，大部分损坏的页都是索引页或者临时数据，真正的业务数据往往在完好的数据页里。最重的是“从备份还原”，适用于物理磁盘坏道、文件系统崩溃这类硬件级损坏，这种就别指望数据库自己修复了，直接上备份，配合日志文件做时间点恢复。
说到这儿，得提一个反直觉的经验：修复命令跑完不代表万事大吉。很多人在REPAIR TABLE成功后就觉得任务完成，第二天系统又报错，一脸懵。实际上，表损坏往往不是孤立事件，它背后可能是磁盘I/O错误、内存校验失败、电压不稳，甚至硬盘快挂了。所以修复完第一件事，是检查系统日志和硬件状态。用smartctl看看硬盘健康度，查查RAID控制器的日志，看看有没有Pending Sector。要是硬件有问题，修好的表随时可能损坏，到时候就不是三步能解决的问题了。
另一个容易被忽略的点：修复操作本身会消耗大量系统资源，尤其是大表。一张几千万行的表跑REPAIR，CPU和I/O可能瞬间被打满，生产环境直接卡死。所以修复前一定要评估业务低谷期，或者干脆在从库上先测试。如果只有单机环境，那就做好服务中断的心理准备，提前通知业务方。有些聪明的做法是先停掉对这张表的写入操作，用只读模式做修复，虽然慢一点，但至少不会产生新的脏数据。
还有个实用技巧，很多老手都在用：对于InnoDB表，如果只是二级索引损坏，可以用ALTER TABLE ... FORCE重建整个表，这个操作比REPAIR TABLE更温和，因为它会重新生成所有索引和数据页，相当于把表“捋一遍”，对数据完整性的保护更好。对于MyISAM表，REPAIR TABLE是标准操作，但要注意它有三个模式：QUICK、EXTENDED、USEFRM。默认的QUICK只修复索引，EXTENDED会逐行检查数据，USEFRM则是重建表定义文件。一般先用QUICK，不行再上EXTENDED，别一上来就USEFRM，那是最后的手段。
说到这儿，得聊聊怎么避免下次再遇到这种糟心事。表损坏这事儿，防大于治。定期做DBCC CHECKDB或者CHECK TABLE，尤其是大表，建议每周跑一次。备份策略要区分：全量备份每天一次，增量备份每几小时一次，日志备份每15分钟一次。更重要的是，备份要定期做恢复演练，别等到真出事了才发现备份文件是坏的。另外，关注数据库的error log，很多问题在早期就有征兆，比如频繁的“Page verification failed”提示，这时候就该提前处理，而不是等表彻底打不开才动手。
三步走完，表是修好了，数据也找回来了，但每次折腾完都得问自己一个问题：为什么坏的是这张表，不是别的？如果答案是硬盘故障，那就赶紧换盘；如果是突然断电，那就上UPS；如果是内存问题，那就调整缓存配置。数据库表损坏就像人感冒，单纯治一次容易，但反复发作就得查查是不是免疫系统出了问题。真正的高手不是会修表，而是让表根本没机会坏。不过话说回来，真遇到表损坏也别慌，深呼吸，按着这三步来：诊断、备份、修复，顺序别乱，数据大概率能救回来。
