多版本并发控制:读取数据时通过一种类似快照的方式将数据保存下来,这样读锁就和写锁不冲突了,不同事务会话看到自己特定版本的数据,使用版本链。
MVCC只在READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作。其他两个隔离级别和MVCC不兼容,因为READ UNCOMMITTED总是读取最新的数据行,而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。
事务版本号:每开启一个事务,我们都会从数据库中获得一个事务ID(也就是事务版本号),这个事务ID是自增长的,通过ID大小,我们就可以判断事务的时间顺序。
行记录的隐藏列:InnoDB的叶子段存储了数据页,数据页中保存了行记录,而在行记录中有一些重要的隐藏字段,如下所示:
db_row_id:隐藏的行ID,用来生成默认的聚簇索引。如果我们创建数据表的时候没有指定聚簇索引,并且没有唯一索引,这时候InnoDB就会使用这个隐藏ID来创建聚簇索引,采用聚簇索引的方式可以提升数据的查询效率。
db_trx_id : 操作这个数据的事务ID,也就是最后一个对该数据进行插入或更新的事务ID。
db_roll_pointer:回滚指针,也就是指向上一个事务的undo log 日志记录 。这样就形成了版本链。
已提交读和可重复读的区别就在于他们生成ReadView的策略不同
ReadView是如何工作的
在mvcc机制中,多个事务对同一个记录进行更新会产生多个历史快照,这些历史快照保存在Undo log里。如果一个事务要查询这些记录,需要读取哪个版本的历史数据呢?这时就需要用到Read View了,它帮我们解决了行的可见性问题。Read View保存了当前事务开启时所有活跃(还没有提交)的事务列表,换个角度可以理解为Read View保存了不应该让这个事务看到的其他事务ID列表。
在Read View中有几个重要属性
trx_ids:系统当前正在活跃的事务ID集合
low_limit_id:活跃的事务中最大的事务ID
up_limit_id:活跃的事务中最小的事务ID
creator_trx_id:创建这个Read View的事务ID
假设当前有事务creator_trx_id想要读取某行记录,这个行记录的事务id为trx_id,那么会出现以下几种情况。
1、如果 trx_id < 活跃的最小事务ID(up_limit_id),也就是说这个行记录在这些活跃事务创建之前就已经提交了,那么这个行记录对该事务是可见的。
2、如果 trx_id > 活跃的最大事务ID(low_limit_id),这说明该行记录在这些活跃的事务创建之后才创建,那么这个行记录对当前事务不可见。
3、如果 up _limit_id < trx_id < low_limit_id ,说明该行记录所在的事务 trx_id在目前creator_trx_id这个事务创建的时候,可能还处于活跃状态,因此我们需要在trx_ids集合中进行遍历,如果trx_id存在于活跃集合中,证明这个事务还处于活跃状态,不可见。否则,不存在于活跃集合中,说明事务已经提交了,该行记录可见。
了解了这写概念之后,我们看一下当查询一条记录的时候,系统如何通过多版本并发控制技术找到它:
1、首先获取事务自己的版本号,也就是事务ID;
2、获取Read View
3、查询得到的数据,然后与Read View中的事务版本号进行比较。
4、如果不符合Read View规则,就需要从Undo log中获取历史快照
5、最后返回符合规则的数据。
已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的Read View,而可重复读隔离级别则在第一次读的时候生成Read View,之后都复用这个Read View。
标签:事务,Read,什么,MVCC,ID,trx,Mysql,id,View From: https://www.cnblogs.com/cuipengchong/p/16708628.html