为什么MySQL需要Undo Log日志_探讨其在事务回滚与MVCC中的核心作用-mysql教程-PHP中文网

Undo Log根本原因有二：保障事务回滚以实现原子性，支撑MVCC快照读以实现可重复读；它记录逻辑反向操作（如UPDATE回滚为原值），并按链表维护时序，同时为每行提供DB_ROLL_PTR指向历史版本链。

为什么mysql需要undo log日志_探讨其在事务回滚与mvcc中的核心作用

MySQL 需要 Undo Log，根本原因就两条：事务回滚必须靠它还原逻辑状态，MVCC 快照读必须靠它提供历史版本——没有它，原子性和可重复读都立不住。

Undo Log 怎么支撑事务回滚（ROLLBACK）

回滚不是“把磁盘文件倒带”，而是按 Undo Log 记录的反向操作逻辑执行撤销。比如执行 UPDATE users SET name = '李四' WHERE id = 1，InnoDB 会在 Undo Log 中写入一条“恢复为原值”的逻辑记录：UPDATE users SET name = '张三' WHERE id = 1。事务未提交前，这条记录一直保留在 Undo Log segment 中。

常见错误现象：

手动 KILL 一个长时间运行的 UPDATE 事务后，发现表没变——其实是回滚在后台异步进行，不是立刻完成；
事务中混合 DML（如先 INSERT 再 UPDATE），回滚时顺序必须严格逆序，Undo Log 按链表结构维护了操作时序，不能靠人工猜。

关键点：

Insert Undo Log 提交即删，Update/Delete 的 Undo Log 提交后仍保留，直到 Purge 线程确认无活跃快照读引用；
回滚操作本身不写 redo log，但 Undo Log 的写入过程是受 redo 保护的——否则连“怎么回滚”都可能丢。

Undo Log 是 MVCC 的数据源，不是辅助工具

MVCC 不是靠锁、也不是靠复制数据行来实现的，而是靠每行记录的 DB_ROLL_PTR 字段，顺着它指向的 Undo Log 版本链，一层层往上找符合事务可见性规则的旧值。SELECT 查询时，InnoDB 根据当前事务的 TRX_ID 和各版本的 TRX_ID、ROLL_PTR 判断该读哪个版本。

典型场景：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

事务 A 执行 UPDATE t SET v = 2 WHERE id = 1 后未提交，事务 B 执行 SELECT v FROM t WHERE id = 1（RR 隔离级别）——B 读到的是旧值，靠的就是 A 写入的 Update Undo Log；
长事务不提交，会拖住 Purge 线程，导致 Undo Log 无法清理，innodb_undo_tablespaces 对应的表空间持续膨胀，甚至触发 ERROR 1114 (HY000): The table is full。

参数影响：

innodb_purge_threads 默认为 4（MySQL 8.0+），线程太少会导致 Purge 滞后；
innodb_max_purge_lag 可控速，但设太小会频繁 throttle DML，别盲目调低。

Undo Log 写入时机和存储位置容易被误判

Undo Log 不是等事务提交才写，而是在第一个 DML 执行前就分配好 Undo Log segment，并立即写入初始日志页。它的生命周期完全由事务状态 + MVCC 可见性共同决定，和 binlog 或 redo log 的刷盘节奏无关。

存储位置差异：

MySQL 5.7 及以前：全部混在系统表空间 ibdata1 里，膨胀后无法收缩，只能 dump & reload；
MySQL 8.0+：默认启用独立 Undo 表空间（innodb_undo_tablespaces = 2），每个表空间可单独截断（ALTER UNDO TABLESPACE ... SET INACTIVE），但必须确保无活跃事务依赖它。

注意：

SHOW ENGINE INNODB STATUS 的 TRANSACTIONS 部分能看到 undo n recs，这是当前事务已生成的 Undo 记录数，不是字节数；
用 information_schema.INNODB_TRX 查长事务时，结合 trx_started 和 trx_mysql_thread_id，才能准确定位是否真在阻塞 Purge。

真正难处理的从来不是“Undo Log 存在哪”，而是“谁还在用它”。一个没提交的事务、一个没关闭的只读连接、甚至一个设置了 SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 却没做任何查询的会话，都可能让某条 Undo Log 多活几小时——这背后是 MVCC 可见性判断与事务生命周期的强耦合，稍不留意，监控看到的只是表象，根因藏在事务快照的持有逻辑里。