innodb的“一致性非锁定读”是rr级别下select默认行为：不加锁、读事务启动时的快照，依赖mvcc和undo log；若undo被清理或活跃事务列表失效，则退化为锁定读。
什么是InnoDB的“一致性非锁定读”
它不是某种开关或配置项，而是SELECT在可重复读（RR）隔离级别下默认的行为：不加锁、读的是某个时间点的快照。关键在于，“不加锁”不等于“不查”，而是避开行锁，靠MVCC（多版本并发控制）回溯到事务开始时已提交的数据版本。
容易误解的是：以为“非锁定读”=“随便读”。其实它严格依赖事务启动时机、undo log保留情况和活跃事务列表——只要这些链路断了，快照就不可用，要么报错，要么退化成锁定读。
RR级别下SELECT什么时候会变成锁定读
显式加锁或隐式触发都会绕过快照读。最常见的是以下几种情况：
- 语句里写了
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE - 在
UPDATE/DELETE语句的WHERE条件中引用了该表，即使没写SELECT，InnoDB也会先做一次当前读来定位记录 - 查询涉及
UNIQUE索引等值查找且记录存在时，如果该记录被其他事务修改但未提交，当前事务可能触发“一致性检查失败”，被迫转为当前读以确认最新状态 - 使用
READ COMMITTED隔离级别时，每次SELECT都重新生成Read View，看似“更实时”，实则快照粒度变细、undo压力更大
READ VIEW是怎么生成和复用的
事务开启第一条SELECT（不含锁）时，InnoDB会创建一个READ VIEW，里面固化了当时所有活跃事务ID的上下界（m_up_limit_id、m_low_limit_id）以及活跃事务ID列表（m_ids）。后续同事务内所有快照读都复用这个视图。
注意几个硬约束：
- 如果事务执行时间太长，而被它引用的旧版本记录对应的undo log已被 purge 线程清理掉，再访问该版本就会报
DB_ROLL_PTR is invalid错误 -
READ VIEW不会跟踪事务中途是否提交/回滚，只看ID是否落在“已提交”区间外；所以长时间运行的事务可能读到“逻辑上已提交但物理上还没落盘”的中间态 - 主从复制中，从库的
READ VIEW生成时机与主库不同步，可能导致GTID模式下出现预期外的快照偏差
怎么验证某次SELECT走的是快照读还是当前读
没有直接SQL能返回“本次读类型”，但可通过组合手段交叉判断：
- 开启
innodb_status_output并查SHOW ENGINE INNODB STATUS输出里的TRANSACTIONS段，观察事务的read view字段是否存在及内容 - 在另一个事务中对同一行做
UPDATE但不提交，然后回到原事务执行SELECT——若立刻返回旧值，大概率是快照读；若卡住或报Lock wait timeout exceeded，说明触发了行锁，是当前读 - 用
performance_schema.data_locks表查当前持有的锁（需开启performance_schema），快照读不会出现在该表中；当前读则会有对应记录 - 注意
information_schema.INNODB_TRX里的TRX_ISOLATION_LEVEL只反映事务级别，不能代表单条语句行为
真正难缠的是混合场景：比如存储过程中嵌套调用、触发器内隐式读、分区表跨分区查询——这些地方的快照边界容易模糊，得靠SHOW PROFILE或慢日志里的lock_time反推。
