mysql事务回滚机制是如何实现的_解析undo log的底层作用-mysql教程-PHP中文网

事务回滚不物理删除数据，而是通过undo log执行逻辑逆操作：insert回滚删主键行、delete回滚插入原数据、update回滚覆写旧值；undo log需先于数据落盘，按lifo顺序解析应用，依赖purge线程清理。

mysql事务回滚机制是如何实现的_解析undo log的底层作用

事务回滚时，MySQL 真的“删数据”了吗？

不是。回滚不等于物理删除或覆盖，而是靠 undo log 做逻辑逆操作。比如你执行了 UPDATE t SET i1 = 502 WHERE id = 50，undo log 会记下这条记录修改前的值（比如 i1 = 501）和主键 id = 50；回滚时，InnoDB 不是把磁盘上那行再改回去，而是读取 undo log，生成一条反向 UPDATE：把 i1 改回 501。

这种设计避免了频繁磁盘寻址，也支撑了 MVCC —— 其他事务读取快照时，可能正依赖这条 undo log 链来获取旧版本。

INSERT 回滚：undo log 只存主键，回滚即执行 DELETE 对应主键行
DELETE 回滚：undo log 存整行原始数据，回滚即执行 INSERT
UPDATE 回滚：记录被改字段的旧值，回滚即用旧值覆盖新值

undo log 写入时机和存储位置很关键

undo log 必须在数据变更写入 Buffer Pool 之前就落盘（或至少写入 undo log buffer），这是原子性的底线。否则事务失败时，连“撤回依据”都没了。

它不单独存在一个文件里，而是存于 InnoDB 的表空间中：

默认在共享表空间 ibdata1 里，由 UNDO_LOG_SEGMENT 管理
MySQL 5.6+ 支持 innodb_undo_tablespaces 拆成多个独立 undo 表空间文件（如 undo001、undo002）
MySQL 8.0 默认开启 innodb_undo_log_truncate，允许在事务提交且无活跃快照后自动截断过期 undo 日志

注意：undo log 不是写完就扔，它要等到所有依赖它的事务（包括正在做 MVCC 读的事务）都结束，才由 purge 线程真正清理。

rollback 执行时，undo log 是怎么被读取和应用的？

InnoDB 回滚不是逐条 SQL 重放，而是按 undo log 记录的物理顺序（LIFO，后进先出）倒着解析并执行逆操作。因为最后做的修改最可能依赖前面的状态，倒序能保证中间状态一致。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

举个例子：

/* 事务内依次执行 */
INSERT INTO t1 VALUES (70, 701);
UPDATE t1 SET i1 = 702 WHERE id = 70;
DELETE FROM t1 WHERE id = 70;

对应生成的 undo log 链是：[delete-log] → [update-log] → [insert-log]。回滚时先处理 delete-log（恢复该行），再 update-log（还原字段），最后 insert-log（删掉插入的行）。

这个过程由 InnoDB 内核在 trx_rollback_for_mysql() 中驱动，全程不走 SQL 解析器，直接操作记录结构，所以比手动写 ROLLBACK 语句快得多。

为什么有时候 rollback 很慢？常见卡点在哪

回滚慢，往往不是 SQL 复杂，而是 undo log 链太长或 purge 延迟导致的资源竞争：

大事务（比如单次更新百万行）会产生海量 undo log，回滚时要逐条解析 + 应用，I/O 和 CPU 压力双高
如果系统里有长事务（比如未提交的只读事务）持续持有快照，purge 线程无法清理旧 undo log，表空间膨胀，回滚时要扫描更多日志
innodb_force_recovery > 0 时，undo 机制可能被禁用，rollback 会直接报错 ERROR 1752 (HY000): Unable to read from the undo log
DDL 操作（如 ALTER TABLE）期间若发生中断，其内部事务的 undo log 可能残留，影响后续回滚行为

真正容易被忽略的是：ROLLBACK 本身不写 binlog，但事务中已生成的 binlog 缓存在 trx cache 中并不会被清空 —— 这意味着如果误用 mysqlbinlog 解析并重放，可能重复执行已回滚的操作。