innodb支持完整acid事务，myisam完全不支持：前者通过redo/undo log实现崩溃自动恢复与精确回滚，后者所有写操作自动提交、无事务状态、无日志恢复，崩溃后需手动repair且易丢数据。
InnoDB 支持完整 ACID 事务，MyISAM 完全不支持 —— 这不是配置问题，是引擎底层能力的硬性差异。
事务命令直接报错：MyISAM 忽略 START TRANSACTION
在 MyISAM 表上执行 START TRANSACTION 不会报错，但后续的 COMMIT 或 ROLLBACK 也无效：所有写操作都是自动提交的。你看到的“事务成功”，其实是每条语句各自落盘，中间出错（比如断电、KILL 进程）就会留下脏数据。
- MyISAM 没有
undo log，无法回滚任何已执行的UPDATE或DELETE - InnoDB 的
ROLLBACK能精确撤销未提交事务中的全部变更，哪怕已修改上千行 - 用
SHOW ENGINE INNODB STATUS可查当前活跃事务；MyISAM 没这个命令，也没状态可查
崩溃后数据一致性：InnoDB 自动恢复，MyISAM 需手动 repair
InnoDB 崩溃重启后，靠 redo log 重放未刷盘的变更、用 undo log 清理未提交事务，整个过程全自动。MyISAM 没日志机制，崩溃后 .MYD 和 .MYI 文件极易错位，常见现象是 Table is marked as crashed 错误，必须人工执行 REPAIR TABLE，且不能保证数据不丢失。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- MyISAM 的
REPAIR TABLE是单线程、阻塞式操作，百万行表可能卡住业务十几分钟 - InnoDB 即使在写入高峰期崩溃，重启后通常几秒内就可对外提供服务
- MySQL 8.0 已将系统表全部迁至 InnoDB，
mysql库里不再允许 MyISAM 表存在
外键与级联操作：只有 InnoDB 支持约束生效
MyISAM 允许你写 FOREIGN KEY 语法，但 MySQL 会静默忽略它 —— 不报错、不建约束、不校验。InnoDB 则会在插入/更新时实时检查，并按定义执行 ON DELETE CASCADE 等动作。
- 在 MyISAM 上删父表记录，子表残留“孤儿数据”是常态，只能靠应用层兜底
- InnoDB 的外键会自动加锁保护关联行，避免并发删除引发不一致
- 即使你没显式定义主键，InnoDB 也会生成隐藏聚簇键来支撑外键和事务日志
真正需要纠结选哪个引擎的场景，现在几乎只存在于遗留系统迁移或极边缘的只读归档表。只要业务逻辑里有任何“要么全成、要么全退”的需求，INSERT 和 UPDATE 不是孤立发生的，就必须用 InnoDB —— MyISAM 的所谓“轻量”优势，在数据错乱风险面前毫无意义。
