InnoDB崩溃后能自动恢复，MyISAM常需人工repair；因InnoDB有redo/undo日志，重启自动重放与回滚，而MyISAM无日志，.MYI或.MYD损坏频发且修复失败率高。
MySQL宕机后InnoDB能自动恢复，MyISAM常需人工repair
因为InnoDB有redo log和undo log双日志机制，崩溃重启时会自动重放未刷盘的事务、回滚未提交的修改；而MyISAM没有日志，宕机后索引文件.MYI或数据文件.MYD损坏是常态，必须手动执行REPAIR TABLE，且失败率高。
innodb_flush_log_at_trx_commit = 1 是可靠性的底线配置
这个参数控制事务日志刷盘时机。设为1时，每次COMMIT都强制写入磁盘，极端情况下最多丢失1秒事务；若设为0或2，宕机可能丢失更多已提交事务。MyISAM即使配了sync_binlog = 1，也无法弥补其无事务日志的缺陷——它连“单语句原子性”都无法保证。
MyISAM表损坏更隐蔽，.MYI索引损坏比.MYD更常见
-
.MYI索引文件损坏往往不报错，查询结果错乱或缺失，但CHECK TABLE可能返回OK - 索引损坏后
REPAIR TABLE依赖.MYD数据完好，若两者都异常，修复大概率失败 - InnoDB的
.ibd文件自带校验和，启动时自动检测并报错，不会静默返回错误数据
InnoDB崩溃恢复无需人工干预，MyISAM修复可能锁表数小时
InnoDB在MySQL服务重启时自动触发crash recovery流程，整个过程对应用透明；而MyISAM执行REPAIR TABLE会锁定整张表，期间所有读写阻塞，大表修复耗时可能达数十分钟——这在生产环境是不可接受的停机风险。真正容易被忽略的是：MyISAM的“轻量”只是表象，它的可靠性成本全堆在运维响应上。
