innodb崩溃后自动恢复，依赖redo log前滚已提交事务、undo log回滚未提交事务；重启时秒级完成，无需人工干预，前提是innodb_flush_log_at_trx_commit=1启用。
InnoDB 更适合故障恢复，MyISAM 在宕机后大概率需要人工干预，且修复失败风险高。
MySQL崩溃后InnoDB自动恢复是怎么工作的
InnoDB 依赖 redo log 和 undo log 实现崩溃后的前滚（replay）与回滚（rollback）。服务重启时，MySQL 自动触发 crash recovery 流程：先用 redo log 把未刷盘的已提交事务补全，再用 undo log 清理未提交事务的残留修改。整个过程秒级完成，应用无感。
关键前提是：innodb_flush_log_at_trx_commit = 1 必须启用。否则即使 InnoDB，也可能丢失最近一秒内已 COMMIT 的事务。
- 日志文件位置固定：
ib_logfile0、ib_logfile1，位于 MySQL 数据目录下 - 恢复无需 DBA 手动命令，只要 mysqld 正常启动就会执行
-
.ibd文件自带校验和，启动时若检测异常会直接报错，不静默返回脏数据
MyISAM 表损坏后为什么 repair 很难成功
MyISAM 没有事务日志，所有写操作直写磁盘。宕机时 .MYD（数据）和 .MYI（索引）极易不同步，常见错误是 Table 'xxx' is marked as crashed and should be repaired。
但 REPAIR TABLE 不是万能解药：
-
.MYI索引损坏比.MYD更常见，且CHECK TABLE可能返回 OK，实际查询结果错乱或缺失 - 修复依赖
.MYD完好；若两者都异常，REPAIR TABLE大概率失败 - 修复过程会锁表，大表可能耗时数十分钟，期间读写完全阻塞
- 没有双写缓冲（doublewrite）或校验机制，无法识别静默损坏
为什么 innodb_flush_log_at_trx_commit = 1 是底线配置
这个参数决定事务日志何时刷盘到磁盘：
-
=1：每次COMMIT都强制fsync到磁盘 → 最多丢失 1 秒事务，满足绝大多数业务的持久性要求 -
=0：日志只写内存，每秒刷一次 → 宕机可能丢失全部未刷盘事务 -
=2：日志写文件系统缓存，但不fsync→ 崩溃+文件系统缓存未落盘，仍可能丢事务
MyISAM 即使配了 sync_binlog = 1，也无法弥补其无日志机制的根本缺陷——它连“单语句原子性”都不保证，更谈不上事务级恢复。
真正容易被忽略的是 MyISAM 的“轻量”假象
MyISAM 表结构简单（.frm+.MYD+.MYI），看起来轻量，但它的可靠性成本全堆在运维响应上：一次宕机，你得人工判断哪张表坏了、是否可修、要不要停服、有没有备份、修完数据对不对……这些时间成本和风险，在生产环境远高于 InnoDB 多占的那点磁盘空间或内存。
