事务能力由存储引擎决定：InnoDB完整支持ACID、四种隔离级别及MVCC；MyISAM和Memory不支持事务，无回滚与日志机制；建表时指定引擎即确定事务行为。
事务和存储引擎是紧密绑定的，MySQL 本身不直接实现事务，而是由具体的存储引擎来提供事务支持。换句话说：有没有事务、事务怎么工作、能支持哪些隔离级别，完全取决于你用的是哪个存储引擎。
事务能力由存储引擎决定
并不是所有存储引擎都支持事务：
- InnoDB：完整支持 ACID 事务，提供行级锁、MVCC、四种标准隔离级别（READ UNCOMMITTED 到 SERIALIZABLE），是 MySQL 默认且推荐用于事务场景的引擎。
- MyISAM：不支持事务，没有 undo/redo 日志机制，只有表级锁，执行 UPDATE 或 DELETE 中断时无法回滚，数据一致性靠应用层保障。
- Memory：不支持事务，数据全在内存，重启即丢失，适合临时缓存类场景。
事务的底层实现依赖存储引擎的组件
以 InnoDB 为例，事务的原子性、持久性、崩溃恢复等能力，全都建立在它的核心结构之上：
- Undo Log：记录事务修改前的数据镜像，用于回滚（ROLLBACK）和 MVCC 多版本读取。
- Redo Log：预写式日志（WAL），先写日志再写数据页，保证即使宕机也能恢复已提交事务的变更。
- Buffer Pool：缓存数据页和索引页，事务的读写操作实际发生在内存中，再通过 Checkpoint 异步刷盘。
- Transaction ID 和 Read View：每个事务有唯一 ID，InnoDB 用 Read View 判断某条记录对当前事务是否可见，这是实现可重复读（RR）隔离级别的关键。
不同引擎对并发问题的处理差异明显
脏读、不可重复读、幻读这些现象是否出现，不仅和设置的隔离级别有关，更取决于引擎是否真正实现了该级别的语义：
- InnoDB 在 REPEATABLE READ 级别下通过间隙锁（Gap Lock）+ Next-Key Lock 防止幻读（对 SELECT ... FOR UPDATE / INSERT / UPDATE / DELETE 有效）；普通 SELECT 则靠 MVCC 实现快照读，避免阻塞。
- MyISAM 根本不处理这些——它连事务都没有，所有读写都是“直来直去”，并发安全只能靠应用加锁或串行化逻辑。
建表时指定引擎，就锁定了事务行为
创建表时不显式指定 ENGINE，默认用 InnoDB（MySQL 5.5.5+），也就默认获得事务能力：
CREATE TABLE t_user (id INT, name VARCHAR(20)) ENGINE=InnoDB;CREATE TABLE t_log (dt DATE, msg TEXT) ENGINE=MyISAM;
上面两个表，前者支持事务、回滚、一致读；后者任何 DML 操作都无法回退，也没有事务日志，ALTER TABLE 会锁整张表。
