当前读:当前读 读取的是记录的最新版本,读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁。
对于日常操作,如:select ... lock in share mode
(共享锁)、select ... for update
、update
、insert
、delete
都是一种当前读。
测试:
当前事务的隔离级别为 可重复读
,在该隔离级别下事务A仍可以读取到事务B新提交的数据,因为在查询语句后面加上了 lock in share mode
共享锁,此时执行的是当前读操作,当然,加排他锁的时候执行的也是当前读操作。
快照读:简单的select操作(不加锁)就算快照读,读取的是记录数据的可见版本,有可能是历史数据,不加锁,是非阻塞读。
测试:
在测试中,我们看到即使事务B提交了数据,事务A中也查询不到。 原因就是因为普通的select是快照读,而在当前默认的RR隔离级别下,开启事务后第一个select语句才是快照读的地方,后面执行相同的select语句都是从快照中获取数据,可能不是当前的最新数据,这样也就保证了可重复读。
MVCC:全称 Multi-Version Concurrency Control
,多版本并发控制。指维护一个数据的多个版本,使得读写操作没有冲突,快照读为mysql实现mvcc提供了一个非阻塞读功能。MVCC的具体实现还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。
在我们创建表的时候除了我们指定的字段外,InnoDB还会自动给我们添加三个隐藏字段:
undo log
,指向上一个版本。前两个字段是一定会生成的,而最后一个字段是否生成则要根据表是否有主键而定。
1)查看stu表中是否含有隐藏字段
进入该表所在的数据库文件 /var/lib/mysql/itcast/
,查看stu的表结构信息:
ibd2sdi stu.ibd
查看表结构信息中,除我们指定的字段外,还有额外的两个字段,分别是:DB_TRX_ID 、 DB_ROLL_PTR ,因为该表有主键,所以没有DB_ROW_ID 隐藏字段。
2)查看没有主键的employee表
ibd2sdi employee.ibd
查看到的表结构信息中,有一栏 columns,在其中我们会看到处理我们建表时指定的字段以外,还有 额外的三个字段 分别是:DB_TRX_ID 、 DB_ROLL_PTR 、DB_ROW_ID,因为employee表是没有 指定主键的。
undo log:回滚日志,在insert、update、delete的时候产生的便于数据回滚的日志。
当insert的时候,产生的undo log日志只在回滚时需要,在事务提交后,可被立即删除。
而update、delete的时候,产生的undo log日志不仅在回滚时需要,在快照读时也需要,不会立即被删除。
有一张表的原始数据为:
有四个并发事务同时在访问这张表:
A.第一步
当事务2执行第一条修改语句时,会记录undo log,记录数据变更之前的样子;然后更新记录,并记录本次操作的事务ID和回滚指针,回滚指针用来指定如果发生回滚,回滚到哪一个版本。
B.第二步
当事务3执行第一条修改语句时,也会记录 undo log
日志,记录数据变更之前的样子;然后更新记录,并且记录本次操作的事务ID和回滚指针,回滚指针用来指定如果发生回滚,回滚到哪一个版本。
C.第三步
当事务4执行第一条修改语句时,也会记录 undo log
日志,记录数据变更之前的样子,然后更新记录,并且记录本次操作的事务ID和回滚指针,回滚指针用来指定如果发生回滚,回滚到哪一个版本。
我们发现,不同事务或相同事务对同一条记录进行修改,会导致该记录的undo log生成一条记录版本链表,链表的头部是最新的旧纪录,链表的尾部是最早的旧纪录。
ReadView(读视图)是快照读,sql执行时MVCC提取数据的依据,记录并维护系统当前活跃的事务(未提交的)id。
Read中包含了四个核心字段:
而在readview中规定了版本链数据的访问规则:
trx_id代表当前undolog版本链对应的事务ID。
条件 | 是否可以访问 | 说明 |
---|---|---|
trx_id == creator_trx_id | 可以访问该版本 | 成立,说明数据是当前这个事务更改的。 |
trx_id < min_trx_id | 可以访问该版本 | 成立,说明数据已经提交了。 |
trx_id > max_trx_id | 不可以访问该版本 | 成立,说明该事务是在 ReadView生成后才开启。 |
min_trx_id <= trx_id <= max_trx_id | 如果trx_id不在m_ids中, 是可以访问该版本的 | 成立,说明数据已经提交。 |
不同的隔离级别,生成ReadView的时机不同:
RC隔离级别下,在事务中每一次执行快照读时生成ReadView。
分析事务5中两次快照读读取数据是如何获取的。
在事务5中,查询了两次id为30的记录,由于隔离级别为READ COMMITTED,所以每一次进行快照读都会生成一个ReadView,那么两次生成的ReadView如下:
那么这两次快照读在获取数据时就需要根据所生成的ReadView以及ReadView的版本链访问规则,到undolog版本链中匹配数据,最终决定此次快照读返回的数据。
A.先来看看第一次快照读具体的读取过程:
在进行匹配时,会从undo log的版本链,从上到下进行挨个匹配:
1)
先匹配这条记录,这条记录对应的trx_id为4,也就是将4带入右侧的匹配规则中。这四条规则都不符合,那么就继续匹配 undo log 版本链的下一条。
2)
匹配第二条,,这条记录对应的trx_id为3,也就是将3带入右侧的匹配规则中。同样是四条规则都不满足,继续匹配版本链的下一条。
3)
匹配第三条,这条记录对应的trx_id为2,也就是将2带入右侧的匹配规则中,满足第二条规则终止匹配,此次快照读返回的数据就是版本链中记录的这条数据。
B.再来看看第二次快照读具体的读取过程:
在进行匹配时,会从undo log的版本链,从上到下进行挨个匹配:
1)
先匹配这条记录,这条记录对应的trx_id为4,也就是将4带入右侧的匹配规则中,四条规则都不符合,继续匹配undo log版本链的下一条。
2)
匹配第二条,这条记录对应的trx_id为3,将3带入右侧的匹配规则中,第二条规则满足,终止匹配,此次快照读,返回的数据就是版本链中记录的这条数据。
RR隔离级别下,仅在事务中第一次执行快照读时生成ReadView,后续复用该ReadView。而RR是可重复读,在一个事务中,执行两次相同的select语句查询到的结果是一致的。
分析mysql是如何做到可重复读的。
在RR隔离级别下,只是在事务中第一次快照读时生成ReadView,后续都是复用该ReadView,那么既然ReadView都一样,ReadView的版本链匹配规则也一样,那么最终快照读返回的结果也是一样的。
所以,MVCC的实现原理就是通过 InnoDB表的隐藏字段,UndoLog版本链,ReadView来实现的。
而MVCC+锁,则实现了事务的隔离性。
事务的隔离性是由MVCC+锁实现的,而一致性则是由redo log与undo log保证。