mysql事务原子性依赖innodb在每条dml执行前写入undo log，确保可逆回滚；update等操作先记原值再改数据页，undo log受redo log保护，rollback是直接覆盖而非重算，非innodb表、ddl隐式提交或连接中断均会破坏原子性。
MySQL转账业务的原子性不是靠START TRANSACTION这一行命令“自动生效”的，而是依赖InnoDB引擎在执行每条DML语句前主动写入undo log，并在异常或ROLLBACK时用它还原数据——没写undo log，就不可能真正回滚。
为什么UPDATE语句执行前必须生成undo log
原子性的物理基础是可逆性。InnoDB不会等事务结束才记录“怎么撤回”，而是在每条UPDATE、INSERT、DELETE真正修改数据页之前，先将原值（或逆向操作逻辑）写入undo log段。
-
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1执行时，InnoDB会先从聚簇索引中读出user_id = 1当前的balance值（比如500），然后把“把balance设为500”这条逻辑写进undo log - 接着才把数据页里的
balance改成400；这个顺序不能颠倒，否则崩溃后无法找回原始值 -
undo log本身也受redo log保护，确保它不丢失——这是原子性+持久性的双重保障
ROLLBACK不是“重放SQL”，而是“按undo log反向恢复”
很多人误以为ROLLBACK是重新执行一遍UPDATE ... +100来“补回来”，其实完全相反：它读取undo log里存的原始值，直接覆盖回去。
- 事务中途崩溃（如断电），MySQL重启后会扫描
undo log，对未提交事务做rollback to savepoint或完整回滚 - 手动执行
ROLLBACK时，InnoDB跳过日志解析，直接用undo log里的镜像值覆盖当前行——比“再算一遍”快且确定 - 注意：
undo log只保存逻辑变更（如“设为500”），不保存完整行镜像，所以空间开销小，但要求事务隔离级别不能破坏MVCC快照一致性
容易被忽略的三个破坏原子性的坑
即使写了BEGIN和COMMIT，原子性仍可能失效，常见于以下场景：
- 隐式提交：在事务中执行
ALTER TABLE、DROP DATABASE等DDL语句，会触发隐式COMMIT，导致前面的DML提前固化，无法回滚 - 非InnoDB表：如果
accounts表用的是MyISAM引擎，START TRANSACTION根本不起作用，ROLLBACK无效，undo log也不存在 - 连接中断未捕获：应用层发起转账后网络断开，MySQL服务端可能已部分执行但客户端收不到
COMMIT响应；此时需依赖innodb_lock_wait_timeout和应用层幂等设计，而非单纯靠事务
真正决定原子性是否成立的，从来不是SQL里有没有TRANSACTION关键字，而是每一行变更背后是否有对应的undo log记录、是否落在InnoDB引擎、以及有没有被DDL或外部因素意外截断。这些细节，往往在压测或故障复盘时才暴露出来。
