怎样修复MySQL数据文件损坏导致的Table is marked as crashed错误

作者：袖梨 2026-06-24

应先执行SHOW TABLE STATUS LIKE 'table_name'查Engine列，或用SELECT ENGINE FROM information_schema.TABLES确认引擎类型；仅当返回MyISAM时，再检查.frm、.MYD、.MYI三文件是否齐全，方可进行后续修复。

这个错误只对 MyISAM 表有意义，InnoDB 表出现该提示基本是误判或残留标记——先确认引擎类型，再决定是否用 myisamchk 或 REPAIR TABLE。

别凭报错就动手修。MySQL 报 Table is marked as crashed，但 InnoDB 表根本不会触发这个提示。真正要查的是表的实际引擎：

执行 SHOW TABLE STATUS LIKE 'your_table_name';，看 Engine 列：如果是 InnoDB，立刻停手，这不是损坏，而是日志残留或备份恢复不干净；
更稳妥的查法：SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'table_name';；
如果返回 MyISAM，再检查磁盘文件：进数据库目录（用 mysql -e "SHOW VARIABLES LIKE 'datadir';" 确认路径），看是否存在 table_name.MYD、table_name.MYI、table_name.frm 三个文件——缺一不可。

只要 MySQL 还能连上、引擎确认是 MyISAM，优先用 SQL 命令在线修复，不用停服务：

REPAIR TABLE table_name; 等价于 QUICK 模式，只重建索引文件（.MYI），快但不校验数据行，适合索引损坏但 SELECT 还能返回结果的场景；
如果报 Failed repairing the table，说明数据页也坏了，得切到 EXTENDED：REPAIR TABLE table_name EXTENDED;——它逐行读取 .MYD 并重建全部索引，耗时长、需要 ≥ 表大小 2 倍的空闲磁盘空间；
只有当 .MYI 文件丢失或 myisamchk -s 显示 “Key file is missing” 时，才考虑 USE_FRM：REPAIR TABLE table_name USE_FRM;，它忽略原索引，按 .FRM 结构硬推，索引全失效，后续必须 ANALYZE TABLE。

在线 REPAIR TABLE 失败后，才轮到 myisamchk。它直接读写磁盘文件，MySQL 必须完全停止：

停服务不是 mysqladmin shutdown，而是 systemctl stop mysql（或 service mysqld stop），然后 ps aux | grep mysqld 确保无残留进程；
进对数据库目录：cd /var/lib/mysql/dbname/（路径以 datadir 输出为准），先备份三文件：cp table_name.{MYD,MYI,FRM} /backup/；
修复命令选 -o（--safe-recover）起步：myisamchk -o table_name.MYI；仍失败再试 myisamchk -r -v table_name.MYI（-v 输出过程，方便定位卡点）；
修复完文件属主默认是 root，MySQL 启动时会因权限拒绝读取——必须立刻执行：chown mysql:mysql table_name.*；
别用不同版本 MySQL 的 myisamchk 工具（比如 MySQL 5.7 的工具去修 8.0 的表），.frm 文件格式不兼容会直接报 ERROR 1033。

修完不是万事大吉。MyISAM 没事务、没崩溃恢复，修好只是临时止血：

重启 MySQL 后，立刻执行 CHECK TABLE table_name;，确认返回 status = 'OK'；
抽样查关键字段、行数、时间戳，比对业务逻辑是否异常（比如某天数据全变成 0000-00-00）；
MyISAM 在 MySQL 8.0 已被官方标记为 deprecated，修复只是过渡手段——应尽快用 ALTER TABLE table_name ENGINE=InnoDB; 迁移，前提是磁盘空间足够、且表无 FULLTEXT 索引等 MyISAM 特有功能依赖。