事务能力完全由存储引擎决定
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 写法也救不了数据一致性。
