InnoDB崩溃后自动恢复，MyISAM需人工修复；因InnoDB有重做日志和双写缓冲，MyISAM仅依赖文件标记且无日志，断电易致数据损坏、服务中断。
innodb_flush_log_at_trx_commit = 1 是安全底线，没配这个，InnoDB 也救不了你；配了它，MyISAM 依然不安全——因为它的“不安全”不是配置能补的。
崩溃后 MySQL 启动时，InnoDB 自动恢复而 MyISAM 卡住报错
MySQL 被 kill -9 或断电重启后，InnoDB 表基本秒级可用；MyISAM 表大概率直接报 Table 'db.t1' is marked as crashed and should be repaired，SELECT 失败。这不是“恢复慢”，是服务能不能继续的问题。
原因很实在：InnoDB 启动时自动执行 crash recovery 流程，靠 ib_logfile0（重做日志）和 ibdata1 中的 doublewrite buffer 前滚已提交事务、回滚未提交修改；MyISAM 没有日志，只靠 .MYI 文件头一个标记位判断“是否 crashed”，标记一异常就拒绝服务，必须人工干预。
常见错误现象：
- 应用监控突然告警“查询超时”，查日志发现全是
Table is marked as crashed - 从库宕机重启后，
SHOW SLAVE STATUS显示Slave_SQL_Running: No，错误日志里卡在某个 MyISAM 表上
MyISAM 的修复不是“还原”，而是“重建索引 + 尝试拼接数据”
MyISAM 执行 REPAIR TABLE 不会读取任何事务上下文，它只是用 .MYD 数据文件反推记录位置，再用 .MYI 索引文件重建结构。一旦两者都不完整，结果就是：
- 丢行（尤其
.MYI损坏时，CHECK TABLE可能返回 OK，但查询结果缺失或错乱） - 主键重复（重建索引时跳过冲突校验）
- 修复失败后无法重试，只能离线跑
myisamchk --recover，期间表完全不可用
而 InnoDB 的 .ibd 文件自带页校验和，启动时自动检测撕裂页（torn page），配合 doublewrite buffer 能把写到一半的 16KB 页救回来；MyISAM 没这层保护，断电写到第 8KB 就真存着半截脏页。
innodb_doublewrite 默认开启，delay_key_write 却让 MyISAM 更危险
InnoDB 的双写缓冲机制默认启用：变更页先顺序写进 ibdata1 的连续 2MB 区域（双写区），落盘成功后再并发写入真实 .ibd 文件。崩溃后恢复时，InnoDB 先检查双写区页是否完整，是则直接覆盖回 .ibd。
MyISAM 的 delay_key_write = ON（默认值）会让索引更新也缓存在内存，断电后连 .MYI 都可能丢失——这意味着你不仅丢了刚写的几行数据，还丢了整张表的索引结构。
性能与兼容性影响：
- 禁用
innodb_doublewrite = OFF等于主动放弃页级损坏防护，生产环境不应碰 - MyISAM 的
REPAIR TABLE时间随表大小线性增长，TB 级别可能耗时数小时 - MySQL 5.7+ 默认禁用 MyISAM 的自动修复功能，需显式配置
myisam_recover_options，否则直接报错退出
真正容易被忽略的是：MyISAM 的“轻量”只在系统永远不崩溃时成立
它不占内存、建表快、COUNT(*) 快——这些优势全建立在“磁盘永不掉电、进程永不异常终止”的假设上。现实里一次意外断电，就可能触发人工修复、数据静默损坏、主从复制中断三连击。而 InnoDB 的可靠性成本是前置的：它多占一点内存、写略慢一点、配置稍复杂一点，换来的是崩溃后无需人盯、不丢数据、不停服务。
