innodb支持完整acid事务，myisam完全不支持——前者依赖redo/undo log实现崩溃自动恢复与精确回滚，后者无日志机制、所有操作自动提交、崩溃后需手动repair且易丢数据。
事务支持不是配置开关，是引擎底层架构决定的
InnoDB 支持事务，MyISAM 不支持——这不是你设个参数就能打开的功能，而是由两套完全不同的数据持久化机制决定的。InnoDB 有 redo log 和 undo log，MyISAM 连日志文件都没有。
你执行 START TRANSACTION 后，在 InnoDB 中会开启一个事务上下文，后续所有 DML 都被纳入这个上下文；而在 MyISAM 中，这条命令根本不会注册任何状态，COMMIT 和 ROLLBACK 也只会静默忽略，语句本身仍立即落盘。
- InnoDB 的
undo log记录了每行变更前的镜像，用于ROLLBACK回滚；MyISAM 没有 undo 机制，UPDATE 或 DELETE 一旦写入 .MYD 文件，就不可逆 - InnoDB 崩溃后靠
redo log重放未刷盘的提交事务、靠undo log清理未提交事务；MyISAM 崩溃后只能靠REPAIR TABLE尝试拼凑 .MYD/.MYI 文件，结果不确定 - MyISAM 允许你写
FOREIGN KEY语法，但 MySQL 会直接丢弃——它连外键校验所需的锁和事务隔离基础都不存在
MyISAM 执行事务命令时的实际表现
很多人误以为“没报错=生效了”，但在 MyISAM 上：START TRANSACTION 不报错、COMMIT 不报错、ROLLBACK 也不报错——但这三者全无效。
典型错误现象：
- 执行两条 UPDATE，第二条因字段超长失败，第一条已写入磁盘，无法撤回
- 事务中插入 100 行，第 50 行触发唯一键冲突中断，前 49 行已落盘，表处于半更新状态
-
KILL掉正在执行的长事务，InnoDB 能自动清理未提交变更；MyISAM 可能留下部分写入的 .MYD 记录，且 .MYI 索引不同步
InnoDB 的事务能力依赖哪些关键组件
InnoDB 的事务不是靠“加个开关”实现的，它是一整套协同工作的子系统：
-
buffer pool缓存页修改，配合redo log实现 crash-safe：即使断电，未刷盘的脏页也能靠日志重放 -
trx_sys管理活跃事务 ID 和回滚段（rollback segment），每个事务分配独立undo log空间 - 聚簇索引结构让行定位和版本链管理成为可能；MyISAM 的非聚簇索引+物理偏移地址模型无法支撑 MVCC 或多版本快照
- 隐式主键（如无显式主键则生成
ROW_ID）是事务日志和锁管理的锚点，MyISAM 允许无主键表，也就失去了这个锚点
为什么不能给 MyISAM “打补丁”加上事务
这不是功能缺失，而是设计范式冲突。MyISAM 的核心假设是“单线程写 + 快速读”，所有设计都围绕这个前提：
- 数据文件（.MYD）和索引文件（.MYI）完全分离，没有统一的日志流来串联它们的一致性
- 表级锁模型下，事务所需的行级锁、间隙锁、意向锁等机制无从落地
- 没有 WAL（Write-Ahead Logging）机制，无法保证“日志先于数据落盘”，原子性无法保障
- MySQL 8.0 已彻底移除对 MyISAM 系统表的支持，官方不再维护其与新事务特性的兼容路径
真正需要纠结选哪个引擎的场景，现在几乎只存在于遗留系统迁移或极边缘的只读归档表。只要业务逻辑里有任何“要么全成、要么全退”的需求，就必须用 InnoDB —— MyISAM 的所谓“轻量”，在数据错乱风险面前毫无意义。
