Undo日志是InnoDB存储引擎为保障事务原子性而设计的核心机制，本质是一类逻辑日志，专门记录数据修改前的旧值或反向操作信息，用于事务回滚和多版本并发控制（MVCC）。
undo日志的核心作用
它解决一个根本问题：事务执行中途失败、被主动中止（ROLLBACK），或数据库意外崩溃时，如何把已写入内存但尚未提交的修改“撤回去”？
保证事务的原子性——要么全做，要么全不做 支撑MVCC快照读——让不同事务能读到各自一致的数据版本，无需加锁 不记录SELECT操作，因为查询不改变数据状态undo日志怎么记录修改操作
每条DML语句（INSERT/UPDATE/DELETE）在缓存页（buffer pool）中生效前，InnoDB都会先生成对应的undo日志条目，并打上当前事务ID（trx_id）、表ID（table_no）、回滚指针（roll_pointer）等关键元信息。
INSERT：记录主键值（单列或联合主键各列长度+值），回滚时执行DELETE DELETE：完整保存被删记录的所有字段内容，回滚时重新INSERT回来；实际物理删除由purge线程延后执行 UPDATE：保存修改前的旧值（包括主键和所有被更新列），回滚时用旧值再UPDATE一次；若更新主键，会拆成DELETE+INSERT两步，生成两条undo日志回滚是怎么发生的
当执行ROLLBACK或事务异常终止时，InnoDB不是“重放”原始SQL，而是沿着该事务关联的undo日志链表，从最新到最旧逐条执行其记录的反向操作：
找到事务对应的undo log segment，定位其最后一条日志 按链表顺序逆向应用：比如刚插入了一条记录，就按日志里的主键把它删掉 过程中直接操作buffer pool中的缓存页，不涉及磁盘IO（除非页已被刷出） 回滚完成后，该事务的undo日志进入“已废弃”状态，后续由purge线程清理undo日志的生命周期与存储
它不是随事务提交就立刻消失，而是保留一段时间，原因有二：一是支持未提交事务的回滚；二是服务其他事务的MVCC读取需求（如可重复读隔离级别下需要访问历史版本）。
默认存放在共享表空间（ibdata1）或独立undo表空间（由innodb_undo_directory指定路径） 采用段（segment）管理，每个回滚段（rollback segment）含1024个undo log segment MySQL 8.0起支持在线截断（innodb_undo_log_truncate=ON），自动回收过期undo空间
