MySQL数据表损坏怎么恢复？断电后Table is marked as crashed的处理思路

做Web开发或运维的朋友，多半见过这句报错：Table is marked as crashed and should be repaired。它常见于MySQL服务异常终止之后——断电、OOM被系统杀掉、磁盘写满，都可能让表文件处于不一致状态。本文按「现象、原因、自查、何时求助」四个层面，把处理思路讲清楚。

为什么会损坏：文件系统视角的一次断电

MySQL的MyISAM引擎把每张表拆成.MYD（数据）、.MYI（索引）、.frm（结构）三个文件；写入时，数据先落操作系统的页缓存，再由内核择机刷盘。如果在刷盘前机器断电，就可能出现数据页写了、索引页没写（或反过来）的不一致状态，重启后MyISAM通过标记发现损坏，报出crashed。

InnoDB情况好一些，redo log和double write机制能保障崩溃恢复，但ibdata1共享表空间模式下的系统表空间损坏、独立表空间模式下.ibd文件与数据字典脱节，同样会造成表无法打开或查询报错。

自查与修复步骤

第一步，先停掉MySQL服务，把数据目录整份复制到另一台机器或另一块盘上再操作，所有修复命令都只针对副本执行。第二步，MyISAM表用myisamchk检查：myisamchk --safe-recover 表名.MYI，加-r参数修复、加-o强制重建索引；表在MySQL 5.7及以下也可用REPAIR TABLE语句在线修复。第三步，InnoDB先尝试自带恢复：在my.cnf中加入innodb_force_recovery=1逐级试到6，能启动就尽快把数据导出重建； innodb_force_recovery大于0时表是只读的，不能再写入。

另外提醒：myisamchk运行期间必须确保MySQL没有访问该表，否则索引会被二次损坏，这是很多新手踩过的坑。

哪些情况该交给专业机构

三种信号意味着问题超出了自助修复范围：一是innodb_force_recovery调到3以上仍无法启动，说明共享表空间或redo log损坏严重；二是.ibd文件本身有坏道或截断，数据页物理上就读不出来；三是既没有备份、又承载了关键业务数据，每一步试错都在消耗最后的恢复机会。

这类情况下，专业机构的做法是从底层解析数据页、按表结构逆向重组记录，再导出为SQL或CSV交付。补天时代在数据库数据恢复领域处理了MySQL、Oracle、SQL Server各类损坏场景，成功率保持行业领先，累计恢复硬盘2万个、服务器及存储3000台。遇到数据库文件损坏且无有效备份，可先拨打0755-83775551做免费评估，公司地址：深圳市福田区华强北深南中路2070号电子科技大厦A座35楼。