Undo日志以链表结构存储每次修改前的完整行记录（含DB_TRX_ID和DB_ROLL_PTR），INSERT仅记主键，UPDATE/DELETE存整行旧值；ReadView在首个SELECT时生成，含m_up_limit_id、m_low_limit_id、m_ids和m_creator_trx_id；可见性判断按固定顺序：先查是否为本事务、再查是否在活跃列表、最后查ID范围。
Undo日志里存的到底是什么结构
Undo日志不是简单地存“上一个值”，而是以链表形式存储每次修改前的完整行记录（包括隐藏字段 DB_TRX_ID 和 DB_ROLL_PTR），构成一条 undo log chain。每条记录通过 DB_ROLL_PTR 指向前一个版本，最新版本在最前面，最早版本在链尾。
关键点在于：只有 INSERT 生成的 undo 日志是“逻辑删除”（只记主键），而 UPDATE/DELETE 生成的是“物理快照”——即整行数据的拷贝。这意味着即使你只改了一个字段，Undo里也存了整行旧值。
常见误区：SELECT 不会触发 Undo 写入；只有 DML 才写 Undo。如果看到大量 ibdata1 增长，大概率是长事务没提交，导致旧版本无法被 purge。
ReadView 是什么时候生成的、包含哪些字段
ReadView 在事务执行第一个 SELECT（或显式开启一致性读）时生成，不是事务启动时。它本质是一组快照元信息，核心字段有四个：
-
m_up_limit_id：活跃事务 ID 的最小值（即尚未分配出去的下一个事务 ID） -
m_low_limit_id：生成 ReadView 时，系统中最大事务 ID + 1 -
m_ids：生成时刻所有活跃读写事务的 ID 列表（非只读事务） -
m_creator_trx_id：当前事务自己的 ID（用于判断能否看到自己写的未提交数据）
注意：REPEATABLE READ 下，同一个事务内后续 SELECT 复用首次生成的 ReadView；READ COMMITTED 则每次 SELECT 都新建 ReadView。
如何判断某条 Undo 版本是否对当前查询可见
MySQL 用 ReadView 对每个版本做可见性判断，规则固定且顺序不能错：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 若版本的
DB_TRX_ID==m_creator_trx_id→ 当前事务自己写的，可见 - 若
DB_TRX_IDm_up_limit_id → 该事务在 ReadView 创建前已提交，可见 - 若
DB_TRX_ID>=m_low_limit_id→ 该事务在 ReadView 创建后才启动，不可见 - 若
DB_TRX_ID在m_ids列表中 → 该事务当时仍在运行，不可见；否则可见
这个判断从 Undo 链头（最新版）开始，逐个向下遍历，直到找到第一个“可见”的版本。如果整条链都不可见，就返回空行（对应幻读场景中的“该行不存在”）。
典型陷阱：长事务会拖住 m_up_limit_id，导致大量旧版本无法 purge，进而撑大 Undo 表空间，甚至阻塞 DDL。
为什么 SELECT * FROM t WHERE id = 1 可能走不到索引上的最新版本
即使 id 是主键，InnoDB 仍需沿着主键索引定位到记录后，再根据该记录的 DB_ROLL_PTR 回溯 Undo 链找可见版本。也就是说，“定位索引”和“版本过滤”是两个阶段。
性能影响明显的情形：
- 更新频繁 + 长事务共存 → Undo 链变长，每次
SELECT都要遍历多个版本 - 使用
READ COMMITTED且并发高 → ReadView 频繁重建，但判断逻辑不变，CPU 开销上升 - 查询条件命中二级索引 → 先查二级索引页，再回表聚簇索引，再查 Undo 链，三重跳转
真正容易被忽略的是：没有 WHERE 条件的 SELECT（如全表扫描）会为每一行重复执行整套可见性判断，此时 Undo 链长度和活跃事务数会直接决定响应时间波动。
