undo log是事务回滚的唯一依据，innodb修改数据前必须先写入旧值，确保原子性；它支撑mvcc版本链构建，由purge线程异步清理，存储于独立表空间更可控。
Undo Log 是事务回滚的唯一依据
没有 Undo Log，ROLLBACK 就是空谈。InnoDB 在修改数据前，必须先将旧值写入 Undo Log——不是可选项，是原子性（Atomicity）的硬性前提。一旦事务中途失败或显式执行 ROLLBACK，InnoDB 只能靠 Undo Log 里存的“上一个状态”来逆向还原，其他任何机制（比如 Redo Log、Buffer Pool 快照）都不提供回退能力。
常见错误现象：ERROR 1205: Deadlock found when trying to get lock 后自动回滚能成功，靠的就是每条修改对应的 Undo Log 记录；但如果 Undo 表空间已满或被误删，回滚会直接失败，报错 Cannot rollback transaction because undo log is not available。
- INSERT 回滚：Undo Log 只存主键，回滚时执行
DELETE物理删除 - UPDATE/DELETE 回滚：Undo Log 存完整行旧值（含隐藏列），回滚时重新
INSERT或恢复原值 - 事务未提交前，Undo Log 一直被持有；提交后不立即释放，而是标记为“可清理”，供 MVCC 复用
Undo Log 支撑 MVCC 的版本链构建
MVCC 不是凭空实现的。InnoDB 的 SELECT 能在不加锁的前提下读到一致性视图，靠的是每行记录的 DB_ROLL_PTR 指针，它指向该行在 Undo Log 中的上一版本。多个并发事务看到不同版本的数据，本质就是顺着这条链往历史找。
使用场景举例：事务 A 执行 UPDATE users SET age = 25 WHERE id = 1，事务 B 在同一时刻执行 SELECT age FROM users WHERE id = 1（且隔离级别为 REPEATABLE READ），B 看到的仍是旧值 20——这个“旧值”就来自 Undo Log 中 A 修改前的那条记录。
- Undo Log 被 Purge 线程异步清理，但前提是确认没有活跃事务还需要该版本
-
innodb_max_purge_lag参数影响 Purge 速度；设得太低会导致 Undo Log 积压，拖慢 DML 性能 - 长事务会阻塞 Purge，进而让 Undo Log 占用持续增长——这是
undo_001文件暴涨的最常见原因
Undo Log 存储位置直接影响运维可控性
MySQL 8.0 默认启用独立 Undo 表空间（undo_001、undo_002），这是和老版本最实质的区别。如果还在用 MySQL 5.5 或 5.6 且没开启 innodb_undo_tablespaces，Undo Log 就混在 ibdata1 里，一旦膨胀就无法收缩，只能重建实例。
验证当前配置：
SELECT TABLESPACE_NAME, FILE_NAME, FILE_TYPE FROM information_schema.FILES WHERE FILE_TYPE = 'UNDO LOG';
- 生产环境必须用独立表空间，通过
innodb_undo_tablespaces设为 ≥2（默认即 2） -
innodb_undo_log_truncate = ON（MySQL 5.7+ 默认开启）允许自动截断过期 Undo 段，但依赖 Purge 进度 - 不要手动删除
undo_*.ibd文件——InnoDB 启动时会校验，缺失则拒绝启动
Undo Log 配置不当会直接拖垮写性能
Undo Log 不是“越小越好”。回滚段（Rollback Segment）数量太少，高并发事务会争抢同一个槽位（Slot），出现 Waiting for a free slot in the rollback segment 等待；太多又浪费内存和文件句柄。
关键参数：
-
innodb_undo_logs（MySQL 5.6–5.7）或innodb_rollback_segments（MySQL 8.0+）：控制回滚段个数，默认 128。OLTP 场景建议保持默认，除非监控到明显槽位争用 -
innodb_undo_directory：指定独立 Undo 表空间路径，务必放在高速磁盘（如 NVMe），避免成为 I/O 瓶颈 - 大事务（如批量 UPDATE 百万行）会生成巨量 Undo Log，应拆分为小事务，否则可能触发
Lock wait timeout exceeded或填满 Undo 表空间
真正容易被忽略的点：Undo Log 的生命周期由事务活跃度和 Purge 进度共同决定，而不是由“事务是否提交”单方面控制。一个看似简单的 SELECT 如果开启了事务但没 COMMIT，就足以让后续所有修改的 Undo Log 无法清理。
