快照读看到事务启动时已提交的数据版本，当前读读最新数据并加锁；前者依赖read view判断可见性，后者绕过read view直接查最新行并用next-key lock防幻读。
什么是快照读，它和当前读到底差在哪
快照读就是不加锁的 select，比如 SELECT * FROM user WHERE id = 1；当前读则是带锁的读，比如 SELECT ... for UPDATE、UPDATE、delete。两者根本区别不在语法，而在「看到哪一版数据」：快照读看到的是事务启动时已提交的版本，当前读一定读最新版，并且会加锁防别人改。
- 快照读依赖
Read View判断哪些事务可见——只认「启动时已提交」或「本事务自己改的」 - 当前读绕过
Read View，直接查最新行，同时用Next-Key Lock锁住记录+间隙，防止幻读 - 同一个事务里，第一次
SELECT生成Read View后，后续所有快照读都复用它（可重复读的关键） - 如果在事务中先执行了
UPDATE再SELECT，这个SELECT还是快照读，但能看到自己刚改的值（因为本事务修改总是可见）
DB_TRX_ID 和 DB_ROLL_PTR 怎么配合 undo log 工作
每行数据背后藏着两个隐藏字段：DB_TRX_ID 记最后一次改动它的事务 ID，DB_ROLL_PTR 指向 undo log 里上一个版本。不是所有修改都写新行——InnoDB 在更新时，会把旧值写进 update undo log，再把新值写入当前行，同时更新这两个字段，形成一条「版本链」。
-
DB_TRX_ID是递增整数，不可回退，事务 ID 越小说明越早提交 -
DB_ROLL_PTR不是指向某张表，而是指向 undo log 中的一段物理地址，靠它才能顺着链往回找历史版本 - undo log 分两类：
insert undo log只在事务回滚时用，事务提交后立刻删；update undo log提交后也不能删，要等所有可能用到它的Read View都结束了才清理 - 如果长事务一直不提交，它生成的
Read View会让老版本一直保留，导致 undo log 膨胀、磁盘占满
为什么 RR 隔离级别下不会不可重复读，却还可能幻读
可重复读（Repeatable Read）靠的是事务启动瞬间拍下的「一致性视图」，即 Read View。只要没显式开启新事务，同一事务内所有快照读都基于这个视图，所以不会出现不可重复读。但幻读是另一回事：它指「同样条件 SELECT 出的行数变了」，而 MVCC 对「新插入的行」默认不可见——除非这行是本事务插的，或者别的事务在你 Read View 生成之后才提交。
- RR 下普通
SELECT看不到其他事务新插入并已提交的行（因为它们的DB_TRX_ID> 你的Read View的up_limit_id） - 但如果执行
SELECT ... FOR UPDATE，就变成当前读，会看到新插入的行，并加锁，这时就可能触发幻读（尤其配合INSERT或UPDATE） - InnoDB 实际用
Next-Key Lock（记录锁 + 间隙锁）来堵住幻读入口，但这只对当前读生效；快照读天然不锁，所以严格说「MVCC 不解决幻读，是锁机制在补位」
线上排查慢查询或锁等待时，怎么验证是不是 MVCC 导致的版本链过长
版本链太长本身不慢，但会导致两个实际问题：一是 SELECT 扫描时要遍历多个旧版本判断可见性，二是 undo log 积压拖慢 purge 线程。典型信号是 SHOW ENGINE INNODB STATUS 里出现大量 history list Length 值超过 10 万，或 purge lag 持续升高。
- 查当前最老活跃事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60，重点关注trx_started时间过久的 - 看 undo log 占用：
SELECT SUM(LENGTH(undo_log)) FROM information_schema.INNODB_METRICS WHERE NAME = 'innodb_undo_log_total_size'（mysql 8.0+） - 避免在业务逻辑里留长事务——比如 spring 的
@Transactional方法里调用了 http 外部接口，这会让事务卡住几十秒 - 监控项必须包含
INFORMATION_SCHEMA.INNODB_METRICS中的innodb_history_list_length，阈值建议设为 5000，超了就告警
MVCC 不是银弹，它让读变轻，但把压力转给了 undo log 管理和版本可见性判断。真正容易被忽略的，是那个默默维持着所有快照读一致性的 Read View——它不存硬盘，不写日志，却决定了一切。