MySQL 事务开始时就分配 undo log segment，但真正写入在 DML 执行时
undo log 不是“事务提交时才生成”，也不是“回滚时临时造的”。它从
START TRANSACTION或第一个 DML（如
INSERT/
UPDATE/
DELETE）执行那一刻起，就由 InnoDB 在
undo tablespace中分配段（segment），并为每一行变更预留空间。关键点在于：只有实际修改数据页前，才会往 undo log page 写入记录（即
undo log record）。
常见误解是“没提交就不写 undo”，其实只要执行了
UPDATE t SET x=2 WHERE id=1，InnoDB 就会立即： 读取原行数据（从聚簇索引或二级索引） 构造一条
TRX_UNDO_UPDATE_REC类型的 undo log record 把这条 record 写入当前活跃的 undo log page（可能触发 page 分配或重用） 再更新聚簇索引记录，并打上
DB_TRX_ID和
DB_ROLL_PTR指针指向该 undo record
INSERT / UPDATE / DELETE 对应的 undo log 类型不同
不同类型 DML 产生的 undo log 结构和用途差异很大，直接影响回滚行为和 purge 效率：
INSERT：生成
TRX_UNDO_INSERT_REC，只存新插入记录的主键值（不含完整字段）。回滚时直接按主键物理删除——不走二级索引清理，所以速度最快
UPDATE：分两种情况：
– 若只改非索引列，生成
TRX_UNDO_UPD_EXIST_REC，存旧行的完整镜像（含所有列）；
– 若改了主键或唯一索引列，等价于
DELETE + INSERT，生成两条 undo record（一删一插）
DELETE：先标记删除（
DB_DELETED_BIT），再生成
TRX_UNDO_DEL_MARK_REC，存被删行的完整镜像；回滚时清除标记位，不恢复数据页物理位置
注意：
DB_ROLL_PTR指向的是 undo log record 的物理地址（
page_no + offset），不是逻辑日志偏移。这意味着跨 page 的 long transaction 可能导致 undo chain 跳转频繁，影响回滚性能。
undo log 何时被 purge 线程真正清理
undo log 不会在事务提交后立刻释放。是否可 purge，取决于系统中是否存在更老的活跃事务（即
trx_sys->min_trx_id）： 只有当某条 undo log record 对应的
trx_idmin_trx_id 时，purge 线程才敢安全删除它 如果有个长事务（比如一个未提交的
SELECT ... FOR UPDATE）卡住 1 小时，所有在这之后提交的事务的 undo log 都无法 purge，
undo_001.ibu文件可能持续膨胀 查看阻塞源可用：
SELECT TRX_ID, TRX_STARTED, TRX_STATE, TRX_QUERY FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5;
特别注意：
innodb_undo_log_truncate=ON并不会立即截断文件，而是等整个 undo tablespace 的 space ID 被标记为可回收后，下次
innodb_undo_tablespaces * 1024pages 空闲才触发 truncate —— 这个周期可能长达数小时。
回滚操作本质是“逆向应用 undo log record”
执行
ROLLBACK时，InnoDB 不是“把数据页恢复到事务开始前”，而是顺着
DB_ROLL_PTR链表，逐条读取 undo record 并执行反向操作： 对
TRX_UNDO_INSERT_REC：调用
row_undo_ins，按主键定位并物理删除 对
TRX_UNDO_UPD_EXIST_REC：调用
row_undo_upd_exist_rec，用 undo 中保存的旧值覆盖当前记录（注意：二级索引更新也会被还原） 对
TRX_UNDO_DEL_MARK_REC：调用
row_undo_mod_del_mark，仅清除
DB_DELETED_BIT标记位
这个过程是单线程、顺序执行的，且不可中断。一个修改了 100 万行的事务，回滚时间往往远超执行时间——尤其当涉及大量二级索引更新时，每条 undo record 都要重新查找并修正索引项。
最易被忽略的一点：如果回滚中途 crash，mysqld 重启后会自动继续 rollback（通过
ibdata1中的
TRX_SYS页面重建 active transaction list），但此时 undo log 已被标记为“in rollback”，不能再被其他事务读取用于 MVCC —— 所以长事务回滚期间，
SELECT查询的性能也可能下降。
