MySQL事务开始时即分配undo log segment，实际写入发生在DML执行时；INSERT生成TRX_UNDO_INSERT_REC，UPDATE/DELETE对应不同undo类型，DB_ROLL_PTR指向物理地址，purge需等待更老事务结束。
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 * 1024 pages 空闲才触发 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 查询的性能也可能下降。
