innodb崩溃后自动恢复，myisam需手动修复；因innodb依赖重做日志和双写缓冲区实现前滚回滚，而myisam无事务日志，仅靠文件标记与索引校验，断电易致撕裂页、数据丢失及主从复制中断。
崩溃后 MySQL 重启时，InnoDB 自动恢复而 MyISAM 卡住不动
MySQL 意外断电或进程被 kill -9 后重启，InnoDB 表基本秒级可用；MyISAM 表大概率报 Table 'db.t1' is marked as crashed and should be repaired，查询直接失败。这不是“慢一点”，而是服务是否能继续的问题。
根本原因在于：InnoDB 依赖 ib_logfile0（重做日志）和 ibdata1 中的双写缓冲区（doublewrite buffer），启动时自动前滚已提交事务、回滚未提交事务；MyISAM 没有事务日志，只能靠文件头标记 + 索引校验猜数据，一旦 .MYI 或 .MYD 不一致，就判定为 crashed。
- InnoDB 的恢复过程完全自动，无需人工干预，
innodb_force_recovery是极少数极端情况才用的兜底开关 - MyISAM 必须手动执行
REPAIR TABLE t1或离线运行myisamchk --recover，期间表不可读写 - MyISAM 的修复不是“还原”，而是“重建索引 + 尝试拼接数据”，丢行、错值、主键重复都是常见结果
磁盘断电导致页损坏，InnoDB 能救回来，MyISAM 直接丢数据
MySQL 写入一个 16KB 数据页时，如果断电发生在写到第 8KB 处，就会产生“撕裂页（torn page）”。InnoDB 的双写缓冲机制让这事几乎无害；MyISAM 没这层保护，.MYD 文件里就真存着半截脏页。
关键点在于：innodb_doublewrite 默认开启，它先把变更页顺序写进 ibdata1 的连续 2MB 区域（双写区），落盘成功后再并发写入真实 .ibd 文件。崩溃后恢复时，InnoDB 先检查双写区里的页是否完整，是则直接覆盖回 .ibd；MyISAM 没这个备份区，REPAIR TABLE 只能靠 .MYI 索引反推 .MYD 偏移，索引若也损坏，就彻底没辙。
- 禁用
innodb_doublewrite=OFF会直接放弃页级损坏防护，不建议在生产环境碰 - MyISAM 的
delay_key_write=ON还会让索引也不落盘，断电后连索引都可能丢失 - 哪怕只是日志表、统计表这类“不重要”数据，用 MyISAM 就得接受某次断电后昨天的 PV 归零
从库复制中断？InnoDB 自动续传，MyISAM 可能永久卡死
主从架构下，从库意外宕机重启后，InnoDB 表能正常拉起并继续应用 relay log；MyISAM 表如果崩溃，复制线程一碰到该表就报错停止，SHOW SLAVE STATUS 显示 Slave_SQL_Running: No，且错误日志里常是 Table is marked as crashed。
这是因为 MyISAM 的崩溃状态会污染整个表文件结构，复制线程无法跳过——它不像 InnoDB 那样有事务边界可定位到具体 binlog position。你得先在从库上手动修表，再 START SLAVE，而此时主库可能已推进几百个事务，主从延迟雪上加霜。
- MyISAM 在主从环境中比单机更危险：主库写入正常，但从库修复失败会导致复制流永久断裂
- InnoDB 的
relay_log_info_repository=TABLE+master_info_repository=TABLE把复制元数据也存在 InnoDB 表里，形成闭环一致性 - 别指望
SET GLOBAL sql_slave_skip_counter=1跳过 MyISAM 表错误——它只对事务型引擎有效
为什么你看到的“MyISAM 修复快”，其实是拿数据换时间
有人测试发现 myisamchk --quick 几秒就跑完，而 InnoDB 崩溃恢复要十几秒，于是觉得 MyISAM “恢复快”。这是典型误解：MyISAM 的“快”是跳过校验、直接重建索引的妥协式修复，InnoDB 的“慢”是逐条核对日志、保证每一行都正确的代价。
真正衡量标准不是耗时，而是恢复后数据是否可信。InnoDB 恢复完，SELECT COUNT(*) 和业务逻辑不会出错；MyISAM 修复完，你得额外跑 CHECK TABLE、比对主库 checksum，甚至查日志确认有没有静默丢行。
- MyISAM 所谓“修复工具多”，本质是容错方案多，不是可靠性高
- InnoDB 的恢复时间取决于未刷盘的 redo log 大小，可通过调大
innodb_log_file_size减少 checkpoint 频率来优化 - 最易被忽略的一点：MyISAM 表即使修复成功，
AUTO_INCREMENT值也可能错乱，尤其在主从环境下
