应先执行SHOW TABLE STATUS LIKE 'table_name'查Engine列，或用SELECT ENGINE FROM information_schema.TABLES确认引擎类型；仅当返回MyISAM时，再检查.frm、.MYD、.MYI三文件是否齐全，方可进行后续修复。
这个错误只对 MyISAM 表有意义，InnoDB 表出现该提示基本是误判或残留标记——先确认引擎类型，再决定是否用 myisamchk 或 REPAIR TABLE。
怎么快速确认是不是 MyISAM 表？
别凭报错就动手修。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三个文件——缺一不可。
REPAIR TABLE 能在线修，但参数选错会失败
只要 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。
myisamchk 必须离线操作，且权限和版本不能错
在线 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 特有功能依赖。
