InnoDB崩溃后能自动重放日志并秒级恢复，MyISAM仅靠不一致的.MYD/.MYI文件备份，修复时静默丢行、主键重复、结果错乱；因InnoDB依赖redo log和doublewrite buffer实现确定性前滚回滚，而MyISAM无事务日志且无页级防护。
崩溃后InnoDB能自动重放，MyISAM备份根本没用
MyISAM的“物理备份”只是把.MYD和.MYI文件拷出来，但断电或kill -9后，这两个文件大概率已不一致——.MYI索引可能指向错误的.MYD偏移，甚至本身是撕裂页。你拿这种备份去恢复，REPAIR TABLE常静默丢行、主键重复、查询结果错乱，而MySQL还可能返回OK。InnoDB的ib_logfile0是顺序写的物理日志，记录的是“某数据页第X偏移处从A改成B”，启动时直接重放，不依赖文件结构完整性。
innodb_flush_log_at_trx_commit = 1才是可靠性的硬门槛
这个参数决定redo log何时刷盘。设为1时，每次COMMIT都强制落盘，极端情况下最多丢失1秒事务；设为0或2，宕机可能丢掉全部未刷盘的已提交事务。MyISAM哪怕配了sync_binlog = 1，也补不了没redo log的缺陷——它连单条INSERT ... SELECT中途崩溃都无法回滚，更别说保证多语句事务原子性。
双写缓冲区让InnoDB能救回撕裂页，MyISAM只能认栽
磁盘写入16KB页时若断电在第8KB处，就产生撕裂页。InnoDB默认开启innodb_doublewrite，先把完整页写进ibdata1里的双写区，落盘成功后再并发写入.ibd。崩溃后恢复时，先校验双写区页是否完整，是则直接覆盖回.ibd。MyISAM没有这层保护，REPAIR TABLE只能靠损坏的.MYI反推.MYD，索引一坏，数据就彻底没辙。
MyISAM修复不是还原，而是重建+猜数据
REPAIR TABLE实际行为是：丢弃原.MYI，扫描.MYD重建索引，再按索引顺序尝试拼接数据行。过程中无法验证主键唯一性、外键约束、字段类型合法性，常见结果包括：
- 重复主键被保留，后续
INSERT直接报错 - TEXT字段截断或乱码，因
.MYD里长度标记已损坏 - 时间字段变成
0000-00-00，因时间戳解析失败 - 修复耗时随表大小线性增长，TB级表可能卡住数小时
InnoDB的崩溃恢复是确定性过程：读ib_logfile0→定位检查点→前滚已提交事务→回滚未提交事务→完成。整个流程秒级，与数据量无关，且不锁表。
