InnoDB不支持REPAIR TABLE，因其未实现ha_repair()接口，设计上依赖崩溃自动恢复（重放redo log、校验page checksum）而非人工修复；MyISAM则因结构分离可重建索引。
InnoDB 不需要频繁执行 REPAIR TABLE，根本原因不是它“不容易坏”，而是它压根不支持这个命令，且损坏后无法用该方式修复。
为什么 REPAIR TABLE 对 InnoDB 会报错
执行 REPAIR TABLE table_name; 时，MySQL 会检查存储引擎是否实现 ha_repair() 接口。MyISAM 实现了它；InnoDB 没有——所以直接报错：Storage engine for the table doesn't support repair。这不是疏漏，是设计使然：InnoDB 的索引和数据强耦合在聚簇结构中，无法像 MyISAM 那样靠重扫 .MYD 文件重建 .MYI 索引树。
InnoDB 用什么替代“修复”动作
它依赖崩溃后的自动恢复流程，而非人工干预式修复：
- 重启时若发现
InnoDB: Database was not shut down normally，会自动触发 crash recovery：重放redo log补全未刷盘的变更 - 读取页时校验
page checksum（默认crc32），不匹配则立刻报错（如ERROR 1034或断言失败），拒绝加载——这是“主动暴露”，不是“没损坏” -
innodb_force_recovery仅用于抢救性导出，设为 1–6 后禁止写入，且不能保证所有数据可读
MyISAM 为什么能靠 REPAIR TABLE 活得久
它的结构松散、无事务耦合：
- .MYI 索引文件与 .MYD 数据文件分离，
REPAIR TABLE本质是丢弃原索引、按 .MYD 顺序重建 B+ 树 - 没有 page checksum，损坏常静默发生（比如只返回漏行结果），反而让人误以为“还能用”
-
myisamchk --recover可离线强制修复，哪怕Key block size is wrong也能硬扛
真正该警惕的其实是“没报错的 InnoDB 损坏”
checksum 校验只覆盖页级完整性，但以下情况它检测不到：
- undo log 损坏导致事务可见性混乱（比如已提交事务查不到）
- ibdata1 中元数据页（如
FIL_PAGE_INODE）损坏，表空间无法识别 - 二级索引与聚簇索引键值不一致（例如因异常中断导致部分索引页更新而主键页未更新）
这类问题不会触发 ERROR 1034，但可能让 SELECT 返回错误结果或死锁——它更隐蔽，也更难验证是否修干净。
