MySQL事务能力完全由存储引擎决定，InnoDB支持ACID，MyISAM不支持；InnoDB通过redo log、undo log、Read View等实现事务特性，MyISAM无日志、无回滚、无隔离级别实质约束。
事务能力完全由存储引擎决定
MySQL 本身不实现事务，它把事务的原子性、一致性、隔离性、持久性（ACID）全部委托给底层存储引擎来实现。换言之：InnoDB 支持事务，MyISAM 和 Memory 就不支持——这不是配置问题，而是设计层面的硬性限制。
-
CREATE TABLE t (id INT) ENGINE=MyISAM;后执行START TRANSACTION; UPDATE t SET id=1; ROLLBACK;，数据依然被改了，因为 MyISAM 根本没有undo log，回滚命令被静默忽略 - 哪怕你把全局事务开关
autocommit=1关掉，对 MyISAM 表也无效；它连事务上下文都不识别 - InnoDB 的事务日志（
redo log）和回滚段（undo log）是物理文件，而 MyISAM 只有.MYD（数据）和.MYI（索引）两个文件，没有日志文件
为什么 InnoDB 能支持可重复读（RR）而 MyISAM 不能
不是“设了 SET TRANSACTION ISOLATION LEVEL REPEATABLE READ 就自动生效”，而是 InnoDB 用 Read View + Undo Log 构建快照，让同一事务中多次 SELECT 看到相同数据；MyISAM 连事务都没有，所谓“隔离级别”只是语法上能设，实际毫无约束力。
- 在 RR 下执行
SELECT * FROM user WHERE id = 100;，InnoDB 返回的是该事务首次读时生成的快照版本；MyISAM 每次都查最新磁盘值，可能刚读完就被其他连接改掉 - InnoDB 的间隙锁（
Gap Lock）和临键锁（Next-Key Lock）只在 RR 及以上才启用，用于防止幻读；MyISAM 没有这些机制，SELECT ... FOR UPDATE会直接报错 - 如果你用
mysqldump --single-transaction备份，它依赖的就是 InnoDB 的 MVCC 快照能力；对 MyISAM 表，这个参数会被忽略，备份过程仍会加全局读锁
建表时不指定 ENGINE 就等于默认用 InnoDB？不一定
MySQL 5.5.5+ 默认引擎确实是 InnoDB，但这个“默认”可能被覆盖——比如某些云数据库托管服务或 Docker 镜像会显式改写 my.cnf 中的 default-storage-engine，或者你在连接后执行过 SET default_storage_engine=MyISAM;。
- 安全做法是：建表时**显式声明**
ENGINE=InnoDB，例如CREATE TABLE log (ts DATETIME) ENGINE=InnoDB; - 检查现有表用什么引擎：
SHOW TABLE STATUS LIKE 'log';，看Engine列值，别只信建表语句是否写了 - ALTER TABLE 修改引擎看似简单：
ALTER TABLE log ENGINE=InnoDB;，但注意：这会重建整张表（copy table），锁表时间取决于数据量；线上大表务必避开高峰期
事务提交后数据还没落盘？那是 InnoDB 的 WAL 机制在起作用
InnoDB 采用预写日志（WAL），COMMIT 成功只代表 redo log 已刷盘，对应的数据页（Buffer Pool 中）可能还在内存里，等后台线程异步刷回磁盘。这就是为什么崩溃恢复时，MySQL 能靠 redo log 把已提交但未写盘的事务补全。
- 如果你关掉了
innodb_flush_log_at_trx_commit=2（每秒刷一次 log），那么断电可能丢失最多 1 秒的已提交事务——性能换安全性，得自己权衡 -
innodb_doublewrite=ON是另一道防线：防止页写入一半崩溃导致数据页损坏；MyISAM 完全没这层保护，坏页只能靠myisamchk修复 - 不要误以为“事务提交了就绝对安全”，真正持久化还要看
sync_binlog、innodb_flush_method等协同配置，单点优化没意义
事务不是开关，是引擎能力的投射。InnoDB 的事务行为背后是 redo log、undo log、Buffer Pool、Read View 这一整套协同结构；而 MyISAM 的“无事务”也不是缺陷，是为纯读场景做的取舍。选错引擎，再严谨的 SQL 写法也救不了数据一致性。
