Undo Log 是事务回滚和MVCC的唯一依据，MySQL InnoDB通过持久化逻辑日志实现回滚，而非内存状态或临时副本；它记录反向操作信息，依赖Redo Log保障自身可靠性，并由Purge线程异步清理。
Undo Log 是事务回滚的唯一依据
MySQL InnoDB 不靠“撤销内存状态”或“临时副本”来实现回滚，而是依赖 undo log 这个持久化、逻辑型日志。只要事务没提交，所有 INSERT/UPDATE/DELETE 操作都会同步生成对应的 undo log 记录——它不保存整页数据，只存够反向操作的信息：比如 INSERT 只记主键，DELETE 记完整旧行，UPDATE 记被改前的字段值。
常见错误现象：ROLLBACK 执行后数据没变、或者报错 Cannot rollback - no transaction is active，往往是因为事务已自动提交（如 autocommit=1 且没显式 BEGIN），根本没生成 undo log；或者事务已提交，undo log 被 purge 线程清理了。
- 事务未提交时，
undo log存在undo buffer或磁盘undo tablespace中，可随时用于回滚 - 事务提交后，
undo log不立即删除，而是标记为“可清理”，等待purge线程异步回收 -
innodb_undo_log_truncate=ON（默认开启）会定期截断过大的 undo 表空间，但不会影响正在被 MVCC 引用的旧版本
Undo Log 和 Redo Log 必须配对写入
undo log 本身也要保证不丢——它不是凭空存在的。InnoDB 在写 undo log 到内存缓冲区（undo buffer）时，会同时生成对应的一条 redo log，确保即使 MySQL 崩溃，重启后也能把 undo log 从重做日志中恢复出来，再支撑后续回滚或 MVCC。
这意味着：没有 redo log 的保护，undo log 就不可靠；反过来，没有 undo log，redo log 再持久也救不回一个执行一半就中断的事务。
-
INSERT操作会先写一条insert undo log，再写redo log记录“插入动作” -
UPDATE会写update undo log（含旧值），同时redo log记录“新值写入 page”的物理变更 - 如果崩溃发生在
undo log写完但redo log未刷盘时，恢复阶段会丢弃该undo log，因为其自身已不可信
Undo Log 直接决定 MVCC 快照读行为
你执行 SELECT 时看到的“一致性视图”，底层就是靠 undo log 链串起来的。每个活跃事务启动时会拿到一个 read view，查询时若发现某行被其他事务修改过，就顺着该行的 DB_ROLL_PTR 指针往 undo log 链上找“本事务可见的最近旧版本”。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
容易踩的坑：long-running transaction 会长期持有 read view，导致 purge 线程无法清理它之后产生的 undo log，最终撑爆 undo tablespace（错误如 ER_TOO_MANY_CONCURRENT_TRXS 或磁盘满）。
-
innodb_max_undo_log_size=1G是单个 undo 表空间上限，超限触发截断，但前提是没被任何事务引用 -
SELECT不产生undo log，但高并发下大量短事务频繁更新同一行，会快速堆积update undo log链 - 隔离级别影响可见性判断逻辑，但无论
READ COMMITTED还是REPEATABLE READ，底层都依赖同一套undo log版本链
手动干预 Undo Log 的边界非常窄
开发者几乎不需要、也不应该直接读写或清理 undo log。它的生命周期完全由 InnoDB 自动管理：事务开始 → 写入 → 提交/回滚 → 标记可 purge → purge thread 回收。你能做的有限操作只有调优几个关键参数。
真正需要警惕的是那些让 undo log 无法释放的场景——比如应用层漏掉 COMMIT 或 ROLLBACK，或者监控缺失导致长时间未提交事务无人察觉。
-
innodb_purge_threads=4（默认）决定了后台清理速度，写密集场景可适当提高 -
innodb_undo_directory建议设为独立 SSD 路径，避免和 ibdata1 争 I/O - 不要关闭
innodb_undo_log_truncate，否则 undo 表空间只增不减
Undo Log 不是调试日志，也不是审计日志；它是事务原子性和 MVCC 的基础设施，一旦损坏或配置失当，轻则性能陡降，重则事务逻辑错乱——而这种问题往往在高负载、长事务、大更新量交汇时才突然暴露。
