undo log在update时记录修改前的完整旧值(逻辑前镜像)及事务元数据,并触发redo log写入;其链式结构支撑mvcc可见性判断,需满足无活跃依赖事务等条件才可清理。

Undo Log在UPDATE执行时到底记了什么
执行 UPDATE t_user SET name='xiaolin' WHERE id=1 时,InnoDB不会直接覆盖原记录,而是先将该行修改前的完整旧值(包括主键、所有字段原始内容、事务ID、回滚指针等)写入Undo Log。这个过程发生在内存中,且会立刻触发一次对Undo Log自身的redo log写入——因为Undo Log本身也要持久化,不能丢。
关键点在于:Undo Log里存的是“逻辑前镜像”,不是物理页快照。比如原记录是 (id=1, name='zhangsan', age=25),那Undo Log就记下这一整行;后续若回滚,InnoDB就用这条记录反向执行一次UPDATE或INSERT/DELETE操作。
常见错误现象:ERROR 1205 (40001): Deadlock found when trying to get lock 往往和Undo Log链过长、清理滞后有关——多个事务反复更新同一行,Undo Log版本链堆积,导致锁等待升级为死锁。
为什么UPDATE后SELECT能读到旧值(MVCC的核心机制)
MVCC不是靠“复制数据”实现的,而是靠每条记录头里的DB_TRX_ID(最近修改该行的事务ID)和DB_ROLL_PTR(指向Undo Log中上一个版本的指针)配合Undo Log链完成的。
当一个事务以READ COMMITTED或REPEATABLE READ隔离级别执行SELECT时:
- 它会拿到自己启动时刻的
read view(包含活跃事务ID列表、最小未提交事务ID等) - 顺着
DB_ROLL_PTR从当前记录开始遍历Undo Log链 - 跳过所有对当前事务不可见的版本(比如被其他未提交事务修改的、或已提交但不在当前
read view可见范围内的) - 直到找到第一个满足可见性规则的版本,返回其内容
所以,即使UPDATE已提交,老事务仍可能通过Undo Log读到旧值——Undo Log不清理,MVCC就一直有效。这也是为什么long running transaction会导致Undo Log无法回收、ibdata1持续膨胀。
Undo Log什么时候被真正删除
Undo Log不会在事务提交后立即删除,必须同时满足两个条件:
- 该Undo Log对应的所有事务都已提交(或回滚)
- 当前系统中**没有任一活跃事务**需要访问该Undo Log中的任何版本(即所有
read view都不再依赖它)
这意味着:
-
SELECT SLEEP(3600)这种长查询,会让它启动时生成的read view长期持有,阻塞Undo Log清理 - 设置
innodb_purge_threads=4可加快后台purge线程扫描和清理速度,但无法绕过可见性约束 - 使用
innodb_undo_log_truncate=ON(MySQL 5.7+)配合innodb_max_undo_log_size,可在空间压力大时自动截断过期Undo表空间,但仅适用于独立Undo表空间配置
容易踩的坑:误以为COMMIT后Undo Log就安全可删——实际上只要有一个事务还没结束,对应的所有旧版本都得留着。
UPDATE语句引发的Undo Log链增长与性能影响
频繁更新同一行(如计数器字段),会在Undo Log中形成一条越来越长的链。每次UPDATE都会新增一个版本节点,并更新原记录的DB_ROLL_PTR指向新节点。
这带来两个实际影响:
-
查询变慢:SELECT需要遍历更长的Undo链才能找到可见版本,尤其在
REPEATABLE READ下,如果事务早于第一次UPDATE启动,就得一路回溯到链底 -
空间放大:每个Undo Log版本都占用独立空间,且默认存于系统表空间
ibdata1中,无法收缩;若用独立Undo表空间,也需定期监控INFORMATION_SCHEMA.INNODB_METRICS中的undo_log_current_size
真实场景建议:对高频更新的热点行,考虑拆分逻辑(如用Redis缓存计数器)、或改用READ COMMITTED降低版本保留压力——但要注意这会失去REPEATABLE READ的可重复读保证。
最常被忽略的一点:Undo Log的写入本身要走WAL流程,即每次写Undo Log都会触发一次redo log刷盘。高并发UPDATE不仅压数据库CPU和Buffer Pool,还会显著抬高磁盘I/O负载,尤其是sync_binlog=1 + innodb_flush_log_at_trx_commit=1组合下。











