InnoDB崩溃后秒级可用，MyISAM常报表损坏需人工修复；根本在于InnoDB具备自动crash recovery、redo log、doublewrite buffer和事务日志，而MyISAM无此机制，仅依赖易失效的标记位与不可靠的索引重建。
崩溃后MySQL重启，InnoDB表秒级可用，MyISAM常卡住报错
MySQL被kill -9或断电后重启，InnoDB表基本立刻能查；MyISAM表大概率直接报Table 'db.t1' is marked as crashed and should be repaired，SELECT失败。这不是“恢复慢”，而是服务是否还能继续的问题。
根本原因在于：InnoDB启动时自动执行crash recovery流程，MyISAM压根没这个机制——它只靠.MYI文件头一个标记位判断“是否crashed”，一旦标记异常，就拒绝服务，必须人工干预。
- InnoDB恢复过程对应用完全透明，无需修改代码或重启应用
- MyISAM执行
REPAIR TABLE会锁整张表，大表修复可能持续几十分钟 - 即使
CHECK TABLE返回OK，MyISAM的.MYI索引损坏也可能静默存在，导致查询结果错乱或缺失
InnoDB靠redo log + doublewrite buffer实现页级防护，MyISAM没有备份层
磁盘写入一个16KB页时，若断电发生在第8KB处，就会产生“撕裂页（torn page）”。InnoDB能救回来，MyISAM直接丢数据。
innodb_doublewrite默认开启：它先把变更页顺序写进ibdata1里的2MB双写区，落盘成功后再并发写入真实.ibd文件。崩溃后，InnoDB先校验双写区页是否完整，是则直接覆盖回.ibd。
- MyISAM没有双写区，
REPAIR TABLE只能靠.MYI反推.MYD偏移——索引若也损坏，就彻底没辙 - 禁用
innodb_doublewrite=OFF等于主动放弃页级损坏防护，生产环境不应碰 - MyISAM的
delay_key_write=ON会让索引也不落盘，断电后连索引都可能丢失
事务日志让InnoDB能精确前滚+回滚，MyISAM连单语句原子性都不保证
InnoDB有ib_logfile0重做日志和undo日志，重启时自动重放已提交但未刷盘的事务、回滚未提交的修改。MyISAM没有事务日志，所谓“修复”只是重建索引+尝试拼接数据，丢行、错值、主键重复都是常见结果。
-
innodb_flush_log_at_trx_commit = 1是可靠性底线：每次COMMIT强制刷盘，最多丢失1秒事务 - MyISAM即使配了
sync_binlog = 1，也无法弥补无事务日志缺陷——它连INSERT ... SELECT中途失败都做不到回滚 - 主从复制场景下，从库宕机重启，InnoDB表能自动续传relay log；MyISAM表崩溃会导致复制线程直接卡死，
Slave_SQL_Running: No
真正容易被忽略的是：MyISAM的“轻量”只在正常运行时成立
它不占内存、建表快、COUNT(*)快——这些优势全建立在“系统永远不崩溃”的假设上。一旦出问题，可靠性成本全堆在运维响应上：人工判断损坏类型、评估修复风险、协调停机窗口、验证修复结果。
InnoDB的.ibd文件自带校验和，启动时自动检测并报错，不会静默返回错误数据；MyISAM的.MYD/.MYI文件没有校验机制，损坏可能长期潜伏。
