MySQL表损坏修复需先确认引擎类型：报“Table is marked as crashed”仅属MyISAM，InnoDB应走崩溃恢复；MyISAM可用REPAIR TABLE QUICK/EXTENDED/USE_FRM模式修复，InnoDB则依赖innodb_force_recovery导出重建，修复后须校验逻辑一致性。
先确认是不是真坏了，别被报错带偏
MySQL 报 Table is marked as crashed 或 Incorrect key file，不代表表一定损坏——InnoDB 表根本不会触发这个提示，它只是 MyISAM 的专属信号。真正要查的是引擎类型：SHOW CREATE TABLE table_name 看 ENGINE= 后面写的是什么；更稳妥的是跑一句：SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'table_name'。返回 MyISAM 才继续往下走，InnoDB 就立刻停手，这不是损坏，是崩溃恢复残留或日志不干净。
CHECK TABLE 只检查，不修复，但结果得看懂
CHECK TABLE 是诊断起点，但它不改任何文件，只告诉你当前状态。不同引擎返回的 Msg_type 含义差异很大：
- MyISAM：返回
Error说明索引树断裂或数据行链接异常，基本无法读取 - InnoDB：返回
OK不代表数据逻辑一致，页校验和通过 ≠ 二级索引与聚簇索引同步 - Memory/CVS：只校验表定义能否加载，不碰数据
加 EXTENDED 参数会让 InnoDB 扫更多页，但线上执行会明显拖慢查询，大表慎用；MyISAM 加了也没多大意义，它本来就是全表扫描。
REPAIR TABLE 只对 MyISAM 有效，模式选错直接失败
确认是 MyISAM 后，优先在线修：REPAIR TABLE table_name 默认等价于 QUICK 模式，只重建 .MYI（索引文件），快但不校验数据行——适合 SELECT 还能返回结果、但 ORDER BY 报错的轻度损坏。
如果报 Failed repairing the table，说明 .MYD（数据文件）也坏了，必须切到 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 或重建索引。
InnoDB 表“损坏”基本靠重启或导出重建
InnoDB 没有 REPAIR TABLE 这回事，报错 The storage engine for the table doesn’t support repair 是正常反馈。轻微损坏通常重启 MySQL 就自动恢复；严重时得靠 innodb_force_recovery。
在配置里加 innodb_force_recovery = 1（值 1~6，从低往高试），启动后立刻用 mysqldump 导出数据，然后删库重建再导入。注意：innodb_force_recovery 启用期间禁止写入，否则可能引发二次损坏。
真正容易被忽略的是：修复成功后 REPAIR TABLE 返回 OK，不代表逻辑正确。MyISAM 修复后可能出现唯一键重复、自增 ID 跳变；InnoDB 强制恢复导出的数据，外键约束和索引需手动重建。抽样查几条关键记录、对比修复前后 COUNT(*)、检查 information_schema.KEY_COLUMN_USAGE，比盯着命令行输出更重要。
