文章详细阐述了在MVCC（多版本并发控制）中，ReadView如何作为判断事务可见性的依据。ReadView包含当前活跃事务集合、最小事务id、最大事务id以及创建ReadView的事务id。根据事务id与ReadView的关系，确定记录是否对当前事务可见并可修改。当事务id在特定范围内时，需进一步判断其是否在活跃事务集合中，以决定记录的可见性。
undo log版本链，通过roll_pointer进行链接，
通过read view在查询的时候判断选择哪个历史版本。
read veiw中包含了：
m_ids（trx_ids ）当前活跃事务集合
min_trx_id（up_limit_id ） 最小事务id（版本链尾）
max_trx_id（low_limit_id ）下一个将要被分配的事务id
creator_trx_id 创建这个read view的事务id
1、如果当前被访问记录的trx_id属性值与ReadView中的creator_trx_id值相同，说明当前事务修改的记录就是在当前事务下操作的，那当然是对我们可见的了，因此可以修改这条记录
2、如果当前被访问记录的trx_id属性值小于ReadView中up_limit_id值，说明(生成该版本的事务在该事务生成readView之间已经提交)即当前事务在开启的时候，这条记录最近依次被其他事务操作的事务已经提交了，所以对这条记录对我们来说也是可以见，可以修改
3、如果当前被访问记录的trx_id属性值大于或者等于ReadView中low_limit_id值，说明(生成该版本的事务在当前事务生成readView之后才开启)即：我们开启事务未修改该记录之前，已经有另外一个事务开启，并且正在修改该事务了，因此，这条记录对我们来说依然是不可见的，我们不能修改
4、如果当前被访问记录的trx_id属性值介于ReadView中 up_limit_id 和 low_limit_id 之间的话，那么此时就需要分情况讨论了
此时我们应该分析该trx_id是否在 trx_ids 中
如果在，说明(创建ReadView时，生成该版本的事务还处于活跃状态)即：当前已经有其它的事务正在修改该条记录，并且还未提交，此时这条记录对我们不可见
如果不在，说明((创建ReadView时，生成该版本的事务已经提交)即：此时没有事务操作该条记录，我们可以修改该条记录
扫一扫
1897
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
