InnoDB崩溃后能自动恢复，MyISAM常需人工repair，根本原因在于InnoDB有redo/undo日志机制，重启时自动重放已提交事务、回滚未提交事务；MyISAM无日志，.MYD与.MYI易不同步，缺乏原子性与一致性保障。
InnoDB崩溃后能自动恢复，MyISAM常需人工 repair —— 根本原因不在“有没有备份”，而在“有没有日志”。
InnoDB 重启时自动重放 redo log，MyISAM 没有这个能力
MySQL 启动时，InnoDB 会检查 ib_logfile0（重做日志）是否完整。若发现未刷盘的已提交事务，就前滚（replay）；若发现未提交事务，则用 undo log 回滚。整个过程无需人工干预，几秒内完成。
MyISAM 完全没有类似机制：.MYD（数据）和 .MYI（索引）文件是独立写入的，断电时极易不同步。比如 INSERT 刚写完 .MYD，.MYI 还没更新，索引就指向了错误位置——查询可能返回空、乱码，甚至静默跳过某些行。
-
CHECK TABLE对 MyISAM 常报 OK，但实际索引已损坏（尤其.MYI） - InnoDB 的
.ibd文件自带页校验和，启动即检测，坏页直接报错，不返回错误数据 - MyISAM 的
REPAIR TABLE依赖.MYD完好才能重建.MYI；两者都异常时，修复大概率失败
innodb_flush_log_at_trx_commit = 1 是可靠性的底线配置
这个参数决定事务日志何时落盘。设为 1 时，每次 COMMIT 都强制写磁盘，极端情况下最多丢失 1 秒事务；设为 0 或 2，宕机可能丢失已提交但未刷盘的日志，导致数据不一致。
MyISAM 即使配了 sync_binlog = 1，也无法弥补其无事务日志的缺陷——它连“单语句原子性”都无法保证。比如一个 UPDATE 修改多行，断在中间，部分行已改、部分未改，没有回滚路径。
- MyISAM 的
delay_key_write = ON会让索引也不落盘，断电后连索引都可能丢失 - InnoDB 的双写缓冲（
innodb_doublewrite）默认开启，可防止页写半截损坏；禁用它等于放弃页级防护
MyISAM 表损坏更隐蔽，InnoDB 恢复更透明
MyISAM 的典型故障现象不是报错，而是“查得到但读不出”或“结果随机缺失”。应用层很难感知，直到业务逻辑出错（如订单状态不更新、统计值归零）。
InnoDB 在崩溃后要么正常启动，要么明确报错（如 Tablespace is missing 或 Corrupted page），不会静默返回错误数据。即使日志损坏导致自动恢复失败，还可启用 innodb_force_recovery 强制启动并导出数据。
- MyISAM 执行
REPAIR TABLE会锁整张表，TB 级别表修复可能耗时数十分钟，期间所有读写阻塞 - InnoDB 恢复时间基本恒定（秒级），与数据量无关；MyISAM 的修复时间随表大小线性增长
- MySQL 5.7+ 默认禁用 MyISAM 自动修复，需显式配置
myisam_recover_options，否则直接退出
真正容易被忽略的是：MyISAM 的“轻量”只是表象，它的可靠性成本全堆在运维响应上——你省下的那点内存和 CPU，最后都变成了凌晨三点的 REPAIR TABLE 和客户投诉。
