innodb RR 隔离级别下的小问题

資深大佬 : whatevers 0

1 、read_view 中维护了系统中活跃事务集合的快照，这些活跃事务 ID 的最小值为 up_limit_id，最大值为 low_limit_id ； SELECT 操作返回结果的可见性是由以下规则决定的：

DB_TRX_ID < up_limit_id  -> 此记录的最后一次修改在 read_view 创建之前，可见  DB_TRX_ID > low_limit_id   -> 此记录的最后一次修改在 read_view 创建之后，不可见  ->  需要用 DB_ROLL_PTR 查找 undo log(此记录的上一次修改)，然后根据 undo log 的 DB_TRX_ID 再计算一次可见性  up_limit_id <= DB_TRX_ID <= low_limit_id -> 需要进一步检查 read_view 中是否含有 DB_TRX_ID  DB_TRX_ID ∉ read_view  -> 此记录的最后一次修改在 read_view 创建之前，可见  DB_TRX_ID ∈ read_view -> 此记录的最后一次修改在 read_view 创建时尚未保存，不可见  -> 需要用 DB_ROLL_PTR 查找 undo log(此记录的上一次修改)，然后根据 undo log 的 DB_TRX_ID 再从头计算一次可见性

2 、RR 隔离级别下：read view 是在 first touch read 时创建的，也就是执行事务中的第一条 SELECT 语句的瞬间，后续所有的 SELECT 都是复用这个 read view，所以能保证每次读取的一致性（可重复读的语义）

按照这个说法，RR 隔离级别下是读取不到其他事务插入的数据的，那为什么还需要 next-key lock 算法加锁来阻止其他事务的插入呢

求大佬解惑

大佬有話說 (9)

資深大佬 : XiLemon

mvcc 可以解决快照读的幻读，当前读还是要用 Next-key lock 吧

資深大佬 : radiocontroller

RR 隔离级别下是读取不到其他事务插入的数据的

資深大佬 : radiocontroller

@radiocontroller RR 隔离级别下是读取不到其他事务插入的数据的，这里是快照读。那为什么还需要 next-key lock 算法加锁来阻止其他事务的插入呢，这里是当前读

資深大佬 : bringyou

我感觉是为了解决幻读

資深大佬 : xixihaha1

mvcc 可以解决“快照读”的幻读问题，但是解决不了“当前读”的幻读问题

主資深大佬 : whatevers

@XiLemon @radiocontroller 恍然大悟，忽略了读的上下文，多谢两位大佬

資深大佬 : awanganddong

备注下：

当前读
当前读是基于临键锁（行锁 + 间歇锁）来实现的，适用于 insert，update，delete，select … for update，select … lock in share mode 语句，以及加锁了的 select 语句。

更新数据时，都是先读后写，而这个读，就是当前读。读取数据时，读取该条数据的已经提交的最新的事务，生成的 readView 。

資深大佬 : YouLMAO

like share and Subscribe

資深大佬 : zzkde

low_limit_id 指的不是系统中活跃事务的最大 ID，应该是系统要生成的下一个事务 ID 。可以试想这种情况：ReadView 创建时，系统中活跃的最大事务 ID 可能已经存在很久了，这期间也会提交事务（在 ReadView 创建时就已提交），这些提交了的事务应该是可见的。