事务原子性靠undo log记录反向操作实现，而非简单回滚；其本质是逻辑日志，按行存储“如何恢复旧值”，配合read view支持MVCC与一致性读，并在ROLLBACK时逐条执行逆操作且写redo保证自身可恢复。
事务原子性不是靠“回滚”实现的，而是靠 undo log 记录“反向操作”
MySQL 的原子性不是事务开始前就承诺“要么全做要么全不做”，而是在执行过程中持续记录 undo log，为可能的回滚留好退路。真正决定是否提交的，是 COMMIT 或 ROLLBACK 时对这些日志的使用方式。
关键点在于：undo log 不是快照，也不是备份数据文件，而是按行记录“怎么把新值改回去”的指令。比如 UPDATE t SET name='b' WHERE id=1 执行时，undo log 里存的是“把 name 改回 'a'”。
- 每条修改语句都会生成对应 undo log record，写入
undo log segment（在系统表空间或独立 undo 表空间中） - undo log 是逻辑日志：记录的是 SQL 语义级操作（如 “将某行的 name 字段设为旧值”），不是物理页变更
- 事务未提交前，其他事务查不到它的修改，靠的是
read view+ undo log 构造一致性读，不是锁住整张表
undo log 在 rollback 时怎么被实际用到
执行 ROLLBACK 时，InnoDB 不是“撤销磁盘写入”，而是顺着当前事务的 undo log 链，从最后一条往前逐条执行逆操作——注意，这个过程本身也写 redo log，确保 rollback 自身可恢复。
常见误解：以为 rollback 是“删掉刚写的脏页”。其实它会再次修改数据页（把新值覆盖回旧值），并记下这次修改的 redo。
- 每个事务有独立的
undo log segment，由TRX_UNDO_INSERT_TRX或TRX_UNDO_UPDATE_TRX类型区分 -
INSERT产生的 undo log 最简单：直接DELETE对应行；UPDATE/DELETE则需恢复旧值，依赖字段原始内容是否还在 page 中（若被 purge 掉就无法构造） - rollback 过程不可被打断，一旦开始就必须完成，否则会导致数据字典与实际页状态不一致
为什么 long transaction 容易导致 undo log 膨胀和 purge 延迟
undo log 不能随便删——只要还有活跃事务（哪怕只是只读事务）依赖某个 read view，它就可能需要访问更早版本的数据，对应的 undo log 就必须保留。这就是 purge 线程卡住的根源。
典型现象：show engine innodb status 里看到 PURGE DONE FOR TRX'S 滞后，或者 information_schema.INNODB_TRX 中有长时间运行的 TRX_STATE = RUNNING 事务。
- 即使一个事务只执行
SELECT，只要没提交，它持有的read view就会阻止 purge 清理它“可能看到”的旧版本 undo -
innodb_max_purge_lag是个软限制，不会强制 kill 事务，只会影响 DML 的延迟插入 - 用
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60可快速定位长事务
undo log 和 redo log 的分工边界在哪
redo log 保证 crash safe（崩溃后能重放已提交事务），undo log 保证事务原子性和 MVCC（多版本并发控制）。两者协作但绝不混用：redo 不管回滚，undo 不管崩溃恢复。
容易混淆的点：有人以为 undo log 也能用于实例恢复。其实不能——崩溃重启后，InnoDB 先用 redo log 把数据页恢复到最新状态（包括未提交事务的修改），再用 undo log 回滚掉所有未提交事务的更改。
- redo log 是物理日志（记录“某页某偏移写入了什么字节”），顺序写、循环覆盖；undo log 是逻辑日志，随机写、长期保留直到被 purge
- 开启
innodb_undo_log_truncate后，当 undo 表空间超过innodb_max_undo_log_size，系统会在空闲时截断最老的 undo log segment，但前提是里面所有事务都已提交且无活跃 read view 依赖 - 5.7+ 默认使用独立 undo 表空间（
innodb_undo_directory），便于管理大小和备份，但初始化后不能降级回系统表空间
undo log 的真实复杂度藏在 purge 触发时机、read view 生效范围、以及 insert undo 和 update undo 的生命周期差异里——这些细节不暴露给应用层，但直接影响长事务、大更新、高并发查询的行为表现。
