InnoDB崩溃后能自动恢复，依赖redo log前滚已提交事务、undo log回滚未提交事务及检查点机制；MyISAM无事务日志，修复不可靠且易丢数据。
MySQL 数据恢复能力几乎完全由存储引擎决定：InnoDB 能自动从崩溃中恢复，MyISAM 则大概率需要人工干预且无法保证数据一致。
为什么 InnoDB 崩溃后能“自己站起来”
InnoDB 的恢复不是靠运气，而是靠三样东西协同工作：redo log、undo log 和检查点（checkpoint）。MySQL 重启时，它会自动读取 ib_logfile* 中未刷盘的已提交事务，前滚（replay）到数据页；再扫描 undo log，把没提交的事务回滚掉。整个过程无需 DBA 操作，只要 innodb_force_recovery=0（默认值），且日志文件没被删或损坏。
- 关键前提：必须启用
innodb_flush_log_at_trx_commit=1，否则事务提交可能只写到操作系统缓存，断电即丢 - 容易踩的坑：有人为提升性能改成 2 或 0，结果服务器宕机后发现最后几秒事务全丢了
- 注意
innodb_log_file_size不宜过小——太小会导致频繁 checkpoint，反而拖慢恢复速度，也增加日志覆盖风险
MyISAM 表一崩就“瘸腿”，修复只是碰运气
MyISAM 没有事务日志，崩溃后表文件（.MYD 和 .MYI）可能处于中间状态：索引指针指向不存在的数据行，或数据块部分写入。这时 REPAIR TABLE 只是尝试重建索引结构，并不校验数据逻辑是否自洽。
-
myisamchk --recover比 SQL 命令更彻底，但要求 MySQL 已停止服务，否则会报错“table is in use” -
--safe-recover是兜底选项，会逐行扫描重建，极慢，且可能丢数据（比如重复键冲突时随机删一条） - 最危险的操作：在没锁表的情况下直接复制
.MYD/.MYI文件做冷备——哪怕只差一个字节没写完，备份就是坏的
混合引擎环境恢复，一致性比速度更重要
如果数据库里既有 InnoDB 表又有 MyISAM 表（比如 WordPress 插件用了 MyISAM），用 mysqldump 备份时，--single-transaction 对 MyISAM 无效，而 --lock-all-tables 又会让所有写入阻塞数分钟。这不是参数选错的问题，是架构缺陷。
- 真实场景中，这类混合库恢复后常出现“用户能登录但订单查不到”——因为 InnoDB 表恢复到了 T1 时间点，MyISAM 表却是 T2 时间点的备份
- 物理备份（如 XtraBackup）对 MyISAM 表只能做全局锁冷拷贝，无法和 InnoDB 的热备份同步时间点
- 唯一稳妥解法：把 MyISAM 表全部迁成 InnoDB，命令是
ALTER TABLE tbl_name ENGINE=InnoDB，迁移前确保innodb_file_per_table=ON
恢复失败时，innodb_force_recovery 不是万能钥匙
当 InnoDB 启动卡在“starting crash recovery”或报错 Database page corruption on disk，有人会立刻设 innodb_force_recovery=4 强行启动导出数据。但这其实是在拆东墙补西墙。
- 级别 1–2：跳过回滚段，可能导出“脏读”数据（已提交但被其他事务改过还没提交的中间态）
- 级别 3–4：禁用插入缓冲和清除操作，后续 DML 可能失败；级别 5–6 更激进，连主键查找都可能绕过，导出的数据结构都可能错乱
- 真正该做的：先用
mysqlcheck --check-upgrade看 ibdata1 是否损坏；再确认磁盘是否有坏道（smartctl -a /dev/sdX）；最后才考虑 force_recovery，且导出后立即重建实例
恢复不是拼参数，而是拼日志完整性、备份时效性和引擎统一性。很多“恢复失败”的案例，根源不在恢复动作本身，而在崩溃前那几分钟——binlog 是否开启、redo log 是否被误删、MyISAM 表是否还在生产环境苟延残喘。
