文章目录
MVCC概述
MVCC
是通过数据行的多个版本管理来实现数据库的 并发控制 。这项技术使得在InnoDB的事务隔离级别下执行一致性读
操作有了保证。就是为了查询一些正在被另一个事务更新的行,并且可以看到它们被更新之前的值,这样在做查询的时候就不用等待另一个事务释放锁。
快照读与当前读
快照读
快照读又叫一致性读
,读取的是快照数据
。不加锁的简单的SELECT
都属于快照读,比如这样:
# 不加锁的非阻塞读,快照读的前提是隔离级别不是串行级别,串行级别下的快照读会退化成当前读。
SELECT * FROM player WHERE ...
当前读
当前读读取的是记录的最新版本(最新数据,而不是历史版本的数据),读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁。
SELECT * FROM student LOCK IN SHARE MODE; # 共享锁
SELECT * FROM student FOR UPDATE; # 排他锁
INSERT INTO student values ... # 排他锁
复习
隔离级别
sql标准认定:
InnoDB采取的方案
隐藏字段、Undo Log版本链
InnoDB的聚簇索引记录都包含两个必要的隐藏列。
- trx_id :每次一个事务对某条聚簇索引记录进行改动时,都会把该事务的 事务id 赋值给trx_id 隐藏列。
- roll_pointer :每次对某条聚簇索引记录进行改动时,都会把旧的版本写入到 undo日志 中,然后这个隐藏列就相当于一个指针,可以通过它来找到该记录修改前的信息。
每次对记录进行改动,都会记录一条undo日志,每条undo日志也都有一个 roll_pointer 属性(INSERT 操作对应的undo日志没有该属性,因为该记录并没有更早的版本
),可以将这些 undo日志都连起来,串成一个链表:
对该记录每次更新后,都会将旧值放到一条 undo日志 中,就算是该记录的一个旧版本,随着更新次数的增多,所有的版本都会被 roll_pointer 属性连接成一个链表,我们把这个链表称之为 版本链 ,版本链的头节点就是当前记录最新的值。
MVCC实现原理
MVCC 的实现依赖于:隐藏字段
、Undo Log
、Read View
。
在MVCC机制中,多个事务对同一个行记录进行更新会产生多个历史快照,这些历史快照保存在Undo Log里。
如果一个事务想要查询这个行记录,需要读取哪个版本的行记录呢?
这时就需要用到ReadView
了,它帮我们解决了行的可见性问题。
ReadView就是事务A在使用MVCC机制进行快照读操作时产生的读视图。当事务启动时,会生成数据库系统当前的一个快照,InnoDB为每个事务构造了一个数组,用来
记录并维护系统当前活跃事务的ID
(“活跃"指的就是,启动了但还没提交)。
Read View重要组成
-
creator_trx_id
:创建这个Read View
的事务ID(事务和ReadView是一一对应的)。
说明:只有在对表中的记录做改动时(执行INSERT、DELETE、UPDATE这些语句时)才会为事务分配事务id,否则在一个只读事务中的事务id值都默认为0。
-
trx_ids
:表示在生成ReadView时当前系统中活跃的读写事务的 事务id列表 。 -
up_limit_id
:活跃的事务中最小的事务ID。(活跃是执行未提交) -
low_limit_id
:表示生成ReadView时系统中应该分配给下一个事务的 id 值。low_limit_id 是系统最大的事务id值,这里要注意是系统中的事务id,需要区别于正在活跃的事务ID。
注意:low_limit_id并不是trx_ids中的最大值,事务id是递增分配的。比如,现在有id为1,2,3这三个事务,之后id为3的事务提交了。那么一个新的读事务在生成ReadView时,trx_ids就包括1和2,up_limit_id的值就是1,low_limit_id的值就是4。(
其实就是待分配给下一个事务的id
)
设计思路
- 使用 READ UNCOMMITTED 隔离级别的事务,由于可以读到未提交事务修改过的记录,所以直接读取记录的最新版本就好了。(
最新版本有可能是修改了未提交,所以会产生脏读
) - 使用 SERIALIZABLE 隔离级别的事务,InnoDB规定使用
加锁的方式
来访问记录。 - 使用
READ COMMITTED
和REPEATABLE READ
隔离级别的事务,都必须保证读到 已经提交了的事务修改过的记录。假如另一个事务已经修改了记录但是尚未提交,是不能直接读取最新版本的记录的,核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的
,这是ReadView
要解决的主要问题
。
ReadView的规则
有了这个ReadView,这样在访问某条记录时,只需要按照下边的步骤判断记录的某个版本是否可见。当前事务绑定一个对应的ReadView
-
如果被访问版本的
trx_id
属性值与ReadView中的creator_trx_id
值相同,意味着当前事务在访问它自己修改过的记录
,所以该版本可以被当前事务访问。 -
如果被访问版本的
trx_id
属性值小于ReadView中的up_limit_id
值,表明生成该版本的事务在当前事务生成ReadView前已经提交
,所以该版本可以被当前事务访问。 -
如果被访问版本的trx_id属性值大于或等于ReadView中的
low_limit_id
值,表明生成该版本的事务在当前事务生成ReadView后才开启
,所以该版本不可以被当前事务访问。 -
如果被访问版本的trx_id属性值在ReadView的
up_limit_id 和 low_limit_id
之间,那就需要判断一下trx_id属性值是不是在trx_ids
列表中:
MVCC整体操作流程
-
- 首先获取事务自己的版本号,也就是事务 ID;
-
- 获取 ReadView;
-
- 查询得到的数据,然后与 ReadView 中的事务版本号进行比较;
-
- 如果不符合 ReadView 规则,就需要从 Undo Log 中获取历史快照;
例子
READ COMMITTED级别事务并发MVCC流程
使用
READ COMMITTED
隔离级别的事务中(三个事务并发
)继续查找这个id 为 1
的记录,如下:
# 使用READ COMMITTED隔离级别的事务
BEGIN;
# SELECT1:Transaction 10、20均未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'
# SELECT2:Transaction 10提交,Transaction 20未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'王五'
每一个SELECT都会重新获取一个新的ReadView,所以会得到不同的值
对于当前并发的事务中绑定的第一个SELECT1的ReadView, creator_trx_id为0,trx_ids为[10,20,0]
(自己的事务id也在里面)
,up_limit_id为10,low_limit_id为21,此时先看最新的版本号为20,在trx_ids里,证明是活跃的,由于隔离级别是READ COMMITTED,不能读取活跃的事务,那只能顺着版本链找到下一个版本,直到不在trx_ids里面,就是8,查询的结果就是张三
REPEATABLE READ级别事务并发MVCC流程
使用
REPEATABLE READ
隔离级别的事务中(三个事务并发)继续查找这个 id 为 1 的记录,如下:
# 使用REPEATABLE READ隔离级别的事务
BEGIN;
# SELECT1:Transaction 10、20均未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'
# SELECT2:Transaction 10提交,Transaction 20未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值仍为'张三',因为所有的ReadView都是同一个
如何解决幻读
假设现在有事务 A 和事务 B 并发执行, 事务 A 的事务 id 为 20 , 事务 B 的事务 id 为 30 。
在开始查询之前,MysqL 会为事务 A
产生一个 ReadView,此时 ReadView 的内容如下: trx_ids= [20,30]
, up_limit_id=20
,low_limit_id=31
, creator_trx_id=20
。
# 事务 A 开始第一次查询数据
select * from student where id >= 1;
- 然后B事务插入两条记录,并提交
# 事务 A 又开第二次查询数据
select * from student where id >= 1;