Undo Log根本原因有二：保障事务回滚以实现原子性，支撑MVCC快照读以实现可重复读；它记录逻辑反向操作（如UPDATE回滚为原值），并按链表维护时序，同时为每行提供DB_ROLL_PTR指向历史版本链。
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 判断该读哪个版本。
典型场景：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 事务 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 可见性判断与事务生命周期的强耦合，稍不留意，监控看到的只是表象，根因藏在事务快照的持有逻辑里。
