浙江龙网

  1. 首页 > 生活百科 > >

一篇了解全MVCC( 二 )

生活百科一篇了解全MVCC


1）可见性算法将要被修改的数据的最新记录中的DB_TRX_ID（当前事务id）取出来，与系统此刻其他活跃事务的id去对比，如果DB_TRX_ID跟Read View的属性做了比较，不符合可见性，那么就通过DB_ROLL_PTR回滚指针去取出undolog中的DB_TRX_ID做比较，即遍历链表中的DB_TRX_ID，直到找到满足条件的DB_TRX_ID ， 这个DB_TRX_ID所在的旧记录就是当前事务能看到的数据 。
2）可见性规则首先要知道Read View中的三个全局属性：

  • trx_list:一个数值列表，用来维护Read View生成时刻系统正活跃的事务ID（1,2,3）
  • up_limit_id:记录trx_list列表中事务ID最小的ID（1）
  • low_limit_id:Read View生成时，系统即将分配的下一个事务ID（4）
具体的比较规则如下：
  • 首先比较DB_TRX_ID < up_limit_id如果小于，则当前事务能看到DB_TRX_ID所在的记录如果大于等于，则进入下一个判断
  • 接下来判断DB_TRX_ID >= low_limit_id如果大于等于，则代表DB_TRX_ID所在的记录在Read View生成后才出现的，那么对于当前事务不可见如果小于 ， 则进入下一步判断
  • 判断DB_TRX_ID是否在活跃事务中，trx_list包含DB_TRX_ID如果包含，则代表在Read View生成的时候，这个事务还是活跃状态，未commit的数据，当前事务也是看不到如果不包含，则说明这个事务在Read View生成之前就已经开始commit，那么修改的结果是能够看见的
流程图如下：
一篇了解全MVCC

文章插图
总结：两种情况可见
  • DB_TRX_ID < up_limit_id
  • DB_TRX_ID不在trx_list范围内 ， 且小于low_limit_id
四、整个流程假设有四个事务同时在执行，如下图所示：
事务1事务2事务3事务4事务开始事务开始事务开始事务开始………修改且已提交进行中快照读进行中 ……… 从上述表格中，我们可以看到，当事务2对某行数据执行了快照读，数据库为该行数据生成一个Read View视图，可以看到事务1和事务3还在活跃状态，事务4在事务2快照读的前一刻提交了更新，所以在Read View中记录了系统当前活跃事务1，3，维护在一个列表中 。同时可以看到up_limit_id的值为1，而low_limit_id为5 ， 如下图所示：
一篇了解全MVCC

文章插图
在上述的例子中 ， 只有事务4修改过该行记录，并且在事务2进行快照读前，就提交了事务，所以该行当前数据的undolog如下所示：
一篇了解全MVCC

文章插图
当事务2在快照读该行记录时，会拿着该行记录的DB_TRX_ID去跟up_limit_id、lower_limit_id和活跃事务列表进行比较，从而判读事务2能看到该行记录的版本是哪个 。具体流程如下：
  • 拿该行记录的事务ID（4）去跟Read View中的up_limit_id（1）相比较 ， 判断是否小于 ， 通过对比发现不小于，所以不符合条件
  • 继续判断4是否大于等于low_limit_id（5），通过比较发现也不大于，所以不符合条件
  • 判断事务4是否处理trx_list列表中，发现不在列表中，那么符合可见性条件
所以事务4修改后提交的最新结果对事务2的快照是可见的，因此事务2读取到的最新数据记录是事务4所提交的版本，而事务4提交的版本也是全局角度的最新版本 。
五、拓展1、当前读读取的是最新版本的记录，读取时还要保证其它并发事务不能修改当前记录，会对读取的记录进行加锁
  • 共享锁：select lock in share mode
  • 排它锁：select for update 、update、 insert 、delete
2、快照/普通读1）概念像不加锁的select操作，就是快照读，即非阻塞读
2）为什么会出现快照读？是基于提高并发性能的考虑，快照读是基于多版本并发控制，即MVCC，可以认为MVCC是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销；
3）存在问题
  • 基于多版本，读到的并不一定是数据的最新版本，可能是之前的历史版本
  • 串行级别下的快照读会退化成当前读
3、RC、RR级别下的InnoDB快照读有什么不同因为Read View生成时机的不同，从而造成RC、RR级别下快照读的结果的不同

上一篇：Sentinel 介绍与下载使用

下一篇：java程序员在交接别人的工作时如何保证顺利交接？