搞数据库的人最怕听到的就是“表坏了”。无论是突然断电、硬盘故障，还是某个程序写死了，数据表一损坏，心跳直接漏半拍。但别慌，这事没那么恐怖。数据表损坏不是世界末日，大多数情况下，花个十几二十分钟，按步骤操作，就能把数据捞回来。今天就跟大家聊点实在的，怎么用三步搞定这事，顺带聊聊背后的门道。
先搞清楚，数据表损坏到底有什么症状。最典型的就是查询报错，比如“Table is marked as crashed”“Can't open file: 'xxx.MYI'”，或者直接卡死在某个操作上。这时候别急着重启服务器，更别手贱去删表重来。第一步，先确认损坏程度。用 MySQL 自带的命令跑一下：。这条命令会告诉你表的状态，是 “OK” 还是 “error”。如果报错里带 “repair”，就进入第二步；如果直接报 “not found”，说明文件可能丢失，情况更复杂，但别慌，后面有办法。
第二步，修复。MySQL 的修复命令很简单：。大部分情况下，这条命令几秒到几分钟就能把表恢复。但有个坑：表越大，修复越慢。我见过一个 100 GB 的表，修复用了快一个小时。所以别傻等，去喝杯水，或者处理其他事务。如果 报错说 “Can't find file”，可能是索引文件或数据文件丢失。这时可以尝试 这个命令行工具，它能更底层地处理。比如 ，或者更强力的 （强制修复）。使用前一定要停掉 MySQL 服务或锁表，避免出现更大问题。
第三步，数据抢救。如果修复命令全部失败，别急着放弃。表损坏不代表数据全没了。可以尝试把可读的数据导出成文本格式，用 ，或者直接用 强制导出。小技巧是：如果表里大部分数据还能读，就只导那些能读的行，跳过损坏的记录。比如写个脚本，逐行遍历表，遇到错误就跳过，把能拿到的数据全部捞出来。我有个朋友，公司数据库崩了，用这招捞回了 95% 的数据，只丢了一小部分索引相关的行。事后总结，定期备份才是真救星，但那是后话。
聊点实际的，为什么表会坏？根本原因有三：硬件问题、软件 bug、人为操作。硬件层面，硬盘坏道、内存错误、电源不稳，都会在写入时导致问题。软件层面，MySQL 的存储引擎比如 MyISAM 对异常关机特别敏感。InnoDB 虽然更稳健，但也不是铁打的。人为操作，如暴力 kill 进程、不按规范关闭服务，都容易把表搞坏。所以，预防比修复更划算。比如使用 InnoDB 引擎、设置 参数、定期执行 ，都是低成本高回报的做法。
还有一个常见坑：修复过程中误操作。比如修复到一半看到报错就慌，直接重启服务器，结果表文件变得面目全非；或者用第三方工具乱点，把索引文件删了。记住，修复前先备份损坏的表文件。哪怕文件已经损坏，备份一份总比没有强。备份命令很简单：。万一修复失败，还能拿原始文件再尝试其他方法。另外，最好在低负载时段进行修复，避免影响线上业务。
别迷信“一键修复”工具。市面上声称能秒修数据库的软件大多是骗钱的。真正靠谱的方案，就是 MySQL 自带的命令加手动排查。如果表是 MyISAM 引擎， 是神器；如果是 InnoDB，则需要用 参数进入安全模式，然后导出数据、重建表。心态稳、步骤对、备份全，数据表损坏这事也就那么回事。下次遇到，别慌，按这三步来，大概率能轻松搞定。
