mysql如何理解事务的原子性实现_mysql undo log工作流程-mysql教程-PHP中文网

事务原子性靠undo log记录反向操作实现，而非简单回滚；其本质是逻辑日志，按行存储“如何恢复旧值”，配合read view支持mvcc与一致性读，并在rollback时逐条执行逆操作且写redo保证自身可恢复。

mysql如何理解事务的原子性实现_mysql undo log工作流程

MySQL 的原子性不是事务开始前就承诺“要么全做要么全不做”，而是在执行过程中持续记录 undo log，为可能的回滚留好退路。真正决定是否提交的，是 COMMIT 或 ROLLBACK 时对这些日志的使用方式。

关键点在于：undo log 不是快照，也不是备份数据文件，而是按行记录“怎么把新值改回去”的指令。比如 UPDATE t SET name='b' WHERE id=1 执行时，undo log 里存的是“把 name 改回 'a'”。

执行 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 过程不可被打断，一旦开始就必须完成，否则会导致数据字典与实际页状态不一致

undo log 不能随便删——只要还有活跃事务（哪怕只是只读事务）依赖某个 read view，它就可能需要访问更早版本的数据，对应的 undo log 就必须保留。这就是 purge 线程卡住的根源。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

典型现象：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 可快速定位长事务

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 的生命周期差异里——这些细节不暴露给应用层，但直接影响长事务、大更新、高并发查询的行为表现。