undo log 的内容管理
1. 逻辑结构与分区（如何组织）
InnoDB 对undo log的管理是层级化的，这种设计是为了支持高并发下的事务处理：
- Undo Tablespace：存放 undo 日志的物理文件。
- Rollback Segment (回滚段)：每个表空间最多支持128个回滚段。
- Undo Slot：每个回滚段包含1024个槽位，每个槽位对应一个Undo Log Segment。
- Undo Log Segment：真正存放日志内容的逻辑段，由多个Undo Page组成。
内容分区（类型分离）：
在同一个 Undo Log Segment 中，日志被分为两类存储，因为它们的生命周期完全不同：
- Insert Undo Log：仅记录
INSERT操作。 - Update Undo Log：记录
UPDATE和DELETE操作。
2. 不同分区的清理策略
| 日志类型 | 包含操作 | 清理触发点 | 清理原因 |
|---|---|---|---|
| Insert Undo | INSERT | 事务提交后 | 插入的数据在提交前只对当前事务可见，提交后没有“旧版本”需要维护，可立即回收。 |
| Update Undo | UPDATE,DELETE | Purge 线程异步清理 | 必须等待当前系统中所有可能访问该版本的ReadView（快照）都关闭后，才能由 Purge 线程回收空间。 |
3. 如何保证事务的原子性（Atomicity）
undo log是实现原子性的物理基础。当事务需要回滚（主动回滚或发生异常）时，MySQL 会利用它执行“逆向操作”：
- 逻辑恢复：如果你
INSERT了一条数据，Undo 会执行DELETE；如果你UPDATE了旧值，Undo 会执行反向UPDATE将其改回去。 - WAL 机制的保护：为了防止宕机导致
undo log丢失，undo log的物理修改也会被记录在redo log中。这保证了即使在回滚过程中崩溃，重启后也能通过redo log找回undo log并继续完成回滚。
4. 如何实现 MVCC（多版本并发控制）
undo log是版本链的“原材料来源”，它通过两个隐藏列管理数据版本：
- 版本链串联：
- 每行记录的
DB_ROLL_PTR（回滚指针）指向该行在undo log中的上一个版本。 - 通过这个指针，多代
Update Undo Log形成了一个单向链表。
- 每行记录的
- 快照读（Snapshot Read）：
- 当事务启动时会生成一个
ReadView。 - 查询时，系统会顺着版本链对比
DB_TRX_ID（事务ID），直到找到一个符合ReadView可见性规则的版本。
- 当事务启动时会生成一个
总结
- 分区管理：按事务类型（Insert/Update）物理隔离，优化空间回收。
- 原子性：提供逻辑上的“反向操作”指令。
- MVCC：充当数据的“历史档案馆”，支撑非阻塞读。