MySQL在REPEATABLE READ下快照读的核心是事务首次非锁定SELECT时生成ReadView并全程复用，后续快照读均基于此静态视图判断行版本可见性，BEGIN不触发ReadView生成，显式只读事务则开启即生成。
MySQL在REPEATABLE READ下执行快照读，核心是事务首次SELECT时生成一个ReadView并全程复用，后续所有普通SELECT都基于这个静态视图判断行版本可见性。
ReadView只在第一次快照读时创建
事务启动（BEGIN）本身不触发ReadView生成；只有执行第一个非锁定读（即不含FOR UPDATE或LOCK IN SHARE MODE的SELECT）时，InnoDB才构建ReadView。此后该事务内所有快照读都复用它，不会随其他事务提交而更新。
- 常见错误现象：误以为
BEGIN就“定格快照”，结果在BEGIN后、首次SELECT前其他事务已提交，这些修改仍会被后续快照读看到——因为ReadView尚未生成 - 使用场景：适合需要多次校验同一数据状态的业务，比如库存预占+扣减+日志记录，要求中间不被并发修改干扰
- 注意：显式只读事务（
START TRANSACTION READ ONLY）会在开启时立即生成ReadView
快照读的可见性由DB_TRX_ID和ReadView共同决定
每次访问某行时，InnoDB沿其版本链（通过DB_ROLL_PTR回溯）查找满足以下任一条件的第一个版本：
-
DB_TRX_IDmin_trx_id：该版本由ReadView生成前已提交的事务写入，可见 -
DB_TRX_ID==creator_trx_id：当前事务自己修改的版本，可见 -
DB_TRX_ID>=max_trx_id或DB_TRX_ID∈m_ids：该版本由活跃事务生成或属于未来事务，不可见
关键点：新插入行的DB_TRX_ID一定大于当前ReadView的max_trx_id，所以快照读永远看不到其他事务在本事务开始后插入的行——这是“看起来不幻读”的根本原因。
快照读不等于全库快照，而是按需构建行级视图
所谓“一致性快照”不是把整张表拷一份，而是对每行单独做可见性判断。这意味着：
- 不同查询可能涉及不同索引路径，但只要走的是快照读，都共享同一个ReadView
- 没有主键或唯一索引的等值查询，仍会走全表扫描+逐行判断，性能开销取决于版本链长度
- 长事务导致
m_ids列表巨大，或大量未purge的undo log，会使可见性判断变慢 - 如果某行从未被修改过，它的
DB_TRX_ID就是初始创建事务ID，判断逻辑不变
真正容易被忽略的是：快照读的“一致性”仅作用于读操作本身；一旦执行UPDATE或SELECT FOR UPDATE，就会切换为当前读，直接读最新已提交版本并加锁——此时看到的数据可能和前一次快照读完全不同。别指望靠RR隔离级别让整个事务“完全静止”。
