mysql事务由存储引擎实现，server层不管理；innodb支持acid事务，含undo/redo log和mvcc，而myisam无事务能力，修改立即落盘且不可回滚。
MySQL Server层根本不管理事务
事务不是MySQL Server层的功能，而是由存储引擎自己实现的。Server层只负责解析SQL、做权限校验、调用引擎接口，它对“事务是否开始”“是否该回滚”“隔离级别怎么生效”一概不管。你执行 START TRANSACTION，Server只是把这条语句转发给当前表所用的引擎；你执行 COMMIT，Server也只是依次通知所有涉及的引擎提交——前提是这些引擎都支持事务。
InnoDB能事务，MyISAM不能，这不是“不支持”，是根本没这个能力
MyISAM 引擎压根没有 undo log、没有事务系统结构、不维护事务ID、也不参与MVCC或行锁。它连“回滚”这个动作都无从实现：没有旧值存哪，改了就直接落盘。所以当你在一个事务里混用 InnoDB 表和 MyISAM 表：
- 对 InnoDB 表的操作会被正常记录
undo log和redo log，可回滚、可持久 - 对 MyISAM 表的修改会立即写磁盘，且无法撤销——哪怕事务最后
ROLLBACK，MyISAM 的数据也早改完了 - Server 层不会阻止这种混合操作，但结果就是“部分持久、部分可逆”，彻底破坏原子性
跨引擎事务在XA协议下有理论支持，但实际几乎不可用
MySQL 支持 XA 事务（XA START/XA COMMIT），理论上可用于协调多个引擎甚至外部系统。但问题在于：
- InnoDB 是唯一完整实现 XA 的引擎；MyISAM、Memory 等根本不响应 XA 命令
- 即使两个 InnoDB 表跨库（不同
database），只要在同一个 MySQL 实例内，仍由同一套事务系统管理，不算真正“跨引擎” - 真正跨实例或跨引擎的 XA 需要外部协调者，且一旦 prepare 阶段失败，容易留下两阶段提交残留（
XA RECOVER能查到但难清理） - 线上极少启用 XA，因性能开销大、死锁更隐蔽、运维复杂度陡增
最常踩的坑：autocommit=ON 时误以为自己在事务里
默认 autocommit=ON，每条 SQL 都是独立事务。这时候哪怕你只操作 InnoDB 表，也根本不存在“跨引擎事务”的问题——因为压根没开启事务。但开发者常犯的错是：
- 没显式
START TRANSACTION，却以为INSERT+UPDATE是一个整体 - 在存储过程中调用多个表操作，未检查各表引擎类型
- 用 ORM（如 Django/SQLAlchemy）时，事务边界被中间件或连接池意外截断
这些问题比“跨引擎不支持”更常见，也更容易导致数据不一致。
真正需要跨引擎协作时，不要指望数据库层统一事务，得靠应用层补偿或最终一致性设计。InnoDB 的事务能力再强，也救不了 MyISAM 那张表——它连事务的门朝哪开都不知道。
