InnoDB通过redo log和undo log实现自动崩溃恢复，重启时重做已提交事务、回滚未提交事务；当日志损坏导致自动恢复失败，可借助innodb_force_recovery强制启动并导出数据，最后重建实例。
事务失败时数据状态是否可控
这是最直接的判断依据。InnoDB 通过 redo log 和 undo log 实现原子性与一致性：执行 BEGIN; INSERT ...; UPDATE ...; COMMIT; 过程中任意一步崩溃，重启后自动回滚未提交部分；MyISAM 没有日志机制，语句一执行就落盘，崩在中间就会留下订单已建但库存没扣、或库存已扣但日志没写等脏数据。
常见错误现象：
- 应用层 try-catch 后手动“补偿”，但网络超时、进程崩溃时补偿逻辑本身不执行
- 主从复制中 MyISAM 表在从库崩溃后 SQL 线程中断，必须人工
REPAIR TABLE，期间同步停滞
高并发写入下锁粒度是否影响业务吞吐
InnoDB 默认行级锁，但前提是 WHERE 条件能命中索引；MyISAM 一律表级锁，哪怕只 UPDATE 一行，整张表读写全被堵住。
实操建议：
- 用户中心表更新
last_login_time：用 InnoDB + 主键或唯一索引WHERE，锁只落在目标行 - 消息队列表按
status = 0批量消费：若该字段无索引，InnoDB 会全表扫描+全表锁——这时问题不在引擎，而在缺失索引 - MyISAM 的写锁优先级高于读锁，一个新
INSERT可能插队阻塞 10 个正在排队的SELECT，造成读饥饿
崩溃后能否自动恢复而不丢数据
InnoDB 依赖 ib_logfile0（重做日志）和双写缓冲，在 mysqld 异常终止后重启时自动前滚未刷盘变更、回滚未提交事务，全程无需人工干预；MyISAM 崩溃后 .MYD 或更常见的 .MYI 文件极易损坏，REPAIR TABLE 不仅可能失败，还可能静默丢数据。
性能与兼容性影响：
- InnoDB 崩溃恢复时间基本恒定（秒级），与数据量无关；MyISAM 的
REPAIR时间随表大小线性增长，TB 级别可能耗时数小时 - MySQL 5.7+ 默认禁用 MyISAM 的
REPAIR功能，需显式开启myisam_recover_options，否则直接报错退出
外键约束与引用完整性是否由数据库保障
InnoDB 支持外键，比如订单表的 customer_id 关联客户表，删客户时可配置 CASCADE 自动清理订单；MyISAM 不支持外键，这类逻辑必须推到应用层实现，极易遗漏或出错。
容易踩的坑：
- 误以为 “我项目没显式用
FOREIGN KEY就不需要 InnoDB”——其实外键只是显性体现，事务、行锁、崩溃恢复才是底层刚需 - 把全文搜索需求当作切换 MyISAM 的理由：MySQL 8.0 的 InnoDB 已支持全部布尔语法，配合
ngram插件也能处理中文分词
真正容易被忽略的是：即使你只读不写，InnoDB 的 SELECT 默认走快照读（MVCC），而 MyISAM 每次都读最新物理数据——这意味着在并发更新场景下，MyISAM 查询结果可能瞬间不一致，且无法控制。
