Read View 构建的历史快照副本。
快照读为什么不用加锁？
简而言之，原因非常直接：InnoDB 从不直接获取最新行数据。每次 SELECT 操作，它都依据当前事务的 Read View，沿着版本链找到“该事务可见的最近版本”。整个过程中，行锁或表锁一概不碰。既然查询的是快照而非实时值，锁机制自然被绕开。
关键逻辑在于：一行被修改但未提交？其他事务完全不可见。若已提交但提交时间晚于当前事务启动，Read View 同样会将其排除。因此，读操作与写操作之间天然不存在冲突，实现了无锁并发。
- 在 RR（可重复读）隔离级别下，
Read View在事务第一次执行SELECT时生成，后续所有查询均复用该视图 - 在 RC（读已提交）隔离级别下，每次
SELECT都会创建新的Read View，因此能够看到其他事务最新提交的数据 - 若提升至串行化隔离级别，
SELECT操作退化为当前读，自动添加共享锁，此时 MVCC 机制直接失效
DB_TRX_ID和DB_ROLL_PTR怎么协同工作？
每一行数据背后，都隐藏着两个系统字段：DB_TRX_ID 记录最后一次修改该行的事务 ID，DB_ROLL_PTR 则指向 undo log 中该行的上一个版本。两者共同构成一条完整的版本链。
以事务 A 更新某行为例：InnoDB 首先将旧值拷贝到 undo log，然后设置新行数据的 DB_ROLL_PTR 指向该旧版本；同时将 DB_TRX_ID 更新为事务 A 的 ID。通过一系列指针串联，多个版本便形成了有序序列。
- 若
DB_TRX_ID = 0，表明该行已被标记为删除 - 若
DB_ROLL_PTR为空，说明该版本是最早的，无法再向上追溯 - 版本链的头部是当前最新数据，尾部是最早的快照，通过
DB_ROLL_PTR回溯即可遍历所有历史版本
Read View怎么判断一行是否可见？
Read View 并非存储在磁盘上的表，而是一组内存中的状态信息，包含：m_ids（创建时的活跃事务 ID 列表）、min_trx_id（其中最小活跃 ID）、max_trx_id（下一个待分配的事务 ID）以及 creator_trx_id（创建该视图的事务 ID）。
可见性判定逻辑非常清晰：将目标行的 DB_TRX_ID 与这组参数逐一比对。
- 如果
DB_TRX_ID小于min_trx_id，说明该行在Read View创建前已提交 → 可见 - 如果
DB_TRX_ID大于等于max_trx_id，说明该行由后续事务写入 → 不可见 - 如果
DB_TRX_ID正好落在m_ids列表中，说明写入事务尚未提交 → 不可见 - 否则（既不在
m_ids中，又满足min_trx_id ≤ DB_TRX_ID），说明该行已提交且早于当前事务启动 → 可见
undo log空间爆满怎么办？
undo log 并非无限增长，它仅保留那些仍可能被访问的历史版本。一旦所有活跃事务不再需要某个版本——例如相关事务均已提交或回滚——Purge 线程便会清理对应的 undo log 段。
然而，长事务往往成为瓶颈。若一个事务长时间不提交，或者 innodb_max_purge_lag 设置过于保守，undo log 将不断累积。这不仅降低 DML 性能，甚至可能引发类似 ERROR 1205: Deadlock found when trying to get lock 的误报。
- 事务内避免长时间操作（如调用外部 HTTP 接口、循环处理大量数据）
- 通过
show engine innodb status监控Purge done for trx's n:n的进度 - 必要时将
innodb_purge_threads调整为 4（默认为 1，适用于高并发场景） - MySQL 5.7 及以上版本，开启
innodb_undo_log_truncate = ON，配合innodb_undo_tablespaces，支持自动截断
真正棘手的往往不是 undo 空间本身，而是那个迟迟不提交的事务——它像锚点般拖住整个版本链，导致所有依赖快照的查询都无法绕过它。
