进阶篇(16) 多版本并发控制

長夜難明
138 阅读11分钟

1. 什么是MVCC

Multiversion Concurrency Control，多版本并发控制。MVCC通过数据行的多版本管理 实现DB的并发控制。这项技术使得在InnoDB的事务隔离级别下执行一致性读操作有了保证。即能查询正在被其他事务更新的行，并且可以看到它们被更新之前的值，这样查询时就不用等待另一个事务释放锁。

2. 快照读与当前读

MVCC在InnoDB中的实现主要是为了提高DB并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能不加锁，非阻塞并发读，这个读指快照读, 而非当前读。当前读是一种加锁的操作，悲观锁的实现。而MVCC本质是采用乐观锁思想的一种方式。

2.1 快照读

又叫一致性读，读取的是快照数据。不加锁的简单的SELECT都属于快照读，即不加锁的非阻塞读。

SELECT * FROM player WHERE ...

之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现基于MVCC，它在很多情况下，避免了加锁操作，降低了开销。

2.2 当前读

读取记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，对读取的记录进行加锁。加锁的 SELECT，或者对数据进行增删改都会进行当前读。

3. 复习

3.1 再谈隔离级别

image.png

MySQL默认隔离级别是可重复读，可以解决脏读和不可重复读，不能解决幻读。想要解决幻读，需要采用串行化，但会大幅降低数据库的事务并发能力。

MVCC可以不采用锁机制，而是通过乐观锁的方式解决不可重复读和幻读!它可在大多情况下替代行级锁，降低系统的开销。 image.png

3.2 隐藏字段、Undo Log版本链

回顾一下undo日志的版本链，对于使用InnoDB的表来说，聚簇索引记录中包含两个隐藏列。

  • trx_id：事务对某条聚簇索引记录改动时，会把该事务的事务id赋值给trx_id。
  • roll_pointer：对某条聚簇索引记录改动时，会把旧的版本写入到undo日志中，该隐藏列是一个指针，可以通过它找到该记录修改前的信息。 image.png

insert undo只在回滚时起作用，提交后该类型的undo日志就没用了，它占用的Undo Log Segment也会被系统回收。

假设两个事务id分别为 10、20 的事务对这条记录进行 UPDATE，操作流程如下：

image.png 每次改动都会记录一条undo日志，每条undo日志也都有一个 roll_pointer 属性 （INSERT操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志 都连起来： image.png 每次更新该记录都会将旧值放到一条undo日志中，即该记录的一个旧版本，随着更新次数增多，所有的版本都会被roll_pointer属性连接成一个链表，即版本链，头节点是当前记录最新的值。

4. MVCC实现原理之ReadView

MVCC 的实现依赖于：隐藏字段、Undo Log、Read View。

4.1 什么是ReadView

事务在使用MVCC机制进行快照读操作时产生的读视图。事务启动时会生成当前DBMS的一个快照，InnoDB为每个事务构造了一个数组，用来记录并维护系统当前活跃事务的ID（启动了但还没提交）。

4.2 设计思路

使用READ UNCOMMITTED的事务，可以读到未提交事务修改的记录，直接读取记录的最新版本即可。

使用SERIALIZABLE的事务，InnoDB规定使用加锁的方式来访问记录。

使用READ COMMITTED和REPEATABLE READ的事务，都必须保证读到已经提交了的事务修改过的记录。ReadView要解决的主要问题：判断版本链中的哪个版本是当前事务可见的。

ReadView主要包含4个内容：

  1. creator_trx_id：创建这个 ReadView 的事务的ID。

说明：只有在对表中的记录做改动时（执行INSERT、DELETE、UPDATE这些语句时）才会为事务分配事务id，只读事务中的事务id值默认0。

  1. trx_ids：生成ReadView时当前系统中活跃的读写事务的事务id列表。

  2. up_limit_id：活跃的事务中最小的事务 ID。

  3. low_limit_id：生成ReadView时系统应分配给下一个事务的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。

举例

trx_ids为trx2、3、5和8的集合，系统的最大事务ID(low_limit_id)为trx8+1(如果之前没有其他的新增事务)，活跃的最小事务ID(up_limit_id)为trx2。

image.png

4.3 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_ids 列表中。
    • 在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问。
    • 不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。

4.4 MVCC整体操作流程

查询一条记录时，系统如何通过MVCC找到它：

  1. 获取事务自己的版本号，即事务 ID；

  2. 获取 ReadView；

  3. 查询得到的数据，然后与 ReadView 中的事务版本号进行比较；

  4. 如果不符合 ReadView 规则，就需要从 Undo Log 中获取历史快照；

  5. 最后返回符合规则的数据。

隔离级别为读已提交时，一个事务中的每一次 SELECT 查询都会重新获取一次Read View： image.png

Read View 可能产生不可重复读或者幻读。

当隔离级别为可重复读的时候，就避免了不可重复读，这是因为一个事务只在第一次 SELECT 时获取一次 Read View，后面所有的 SELECT 都复用这个 Read View： image.png

5. 举例说明

假设现在student表中只有一条由事务id=8的事务插入的一条记录：

insert into student values(1, '张三', '一班')

MVCC 只在读已提交和可重复读的隔离条件下起作用

5.1 READ COMMITTED隔离级别下

READ COMMITTED的事务：每次读取数据前都生成一个ReadView。

有两个事务id为10、20的事务在执行：

# Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...

此刻，表student 中 id 为 1 的记录得到的版本链表如下所示： image.png 现在有一个READ COMMITTED隔离级别的事务开始执行：

BEGIN;
# SELECT1：Transaction 10、20未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'

SELECT1的过程如下：

  1. 执行SELECT语句时前生成一个ReadView ，trx_ids列表的内容为[10，20]，up_limit_id为10，low_limit_id为21, creator_trx_id为0(只读事务的事务id值默认为0)。
  2. 从版本链中挑选可见的记录，图中可知最新版本的name为王五，该版本的trx_id值为10，在trx_ids列表内，不符合可见性要求，根据roll_pointer跳到下一个版本。
  3. 下一个版本李四，trx_id值也为10，也在trx_ids列表内，不符合要求，继续跳。
  4. 下一个版本的name是张三，trx_id值为8，小于ReadView中的up_limit_id值10，符合要求，为返回给用户的版本。

之后，我们把 事务id 为 10 的事务提交一下：

# Transaction 10
BEGIN;
UPDATE student SET name="李四" WHERE id=1;
UPDATE student SET name="王五" WHERE id=1;
COMMIT;

然后再到 事务id 为 20 的事务中更新一下表 student 中 id 为 1 的记录：

# Transaction 20
BEGIN;
# 更新了一些别的表的记录
...
UPDATE student SET name="钱七" WHERE id=1;
UPDATE student SET name="宋八" WHERE id=1;

此刻，表student中 id 为 1 的记录的版本链就长这样：

image.png 然后再到刚才的事务中继续查找这个 id 为 1 的记录，如下：

BEGIN;
# SELECT1：Transaction 10、20均未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'张三'
# SELECT2：Transaction 10提交，Transaction 20未提交
SELECT * FROM student WHERE id = 1; # 得到的列name的值为'王五'

SELECT2执行过程如下：

  1. 执行SELECT语句时又生成一个ReadView，其trx_ids列表的内容为[20]，up_limit_id为20，low_limit_id为21, creator_trx_id为0。
  2. 从版本链中挑选可见的记录，图中可知最新版本的name为宋八，该版本的trx_id值为20，在trx_ids列表内，不符合可见性要求，根据roll_pointer跳到下一个版本。
  3. 下一个版本钱七，trx_id值也为20，也在trx_ids列表内，不符合要求，继续跳。
  4. 下一个版本的name是王五，trx_id值为10，小于ReadView中的up_limit_id值20，符合要求，为返回给用户的版本。

再次强调：READ COMMITTED的事务每次读取数据前都生成一个ReadView。

5.2 REPEATABLE READ隔离级别下

REPEATABLE READ的事务：只会在第一次执行查询语句时生成一个 ReadView

5.3 如何解决幻读(在repeatable read隔离级别)

假设现在表 student 中只有一条数据，它的 undo log 如下图所示：
image.png
事务 A 和事务 B 并发执行，事务 A的事务 id 为20，事务 B的事务 id 为30。

步骤1：事务 A 开始第一次查询数据，查询的 SQL 语句如下。

select * from student where id >= 1;

开始查询前，MySQL为事务A产生一个 ReadView，此时 ReadView 的内容如下：trx_ids= [20,30]，up_limit_id=20，low_limit_id=31，creator_trx_id=20。

由于此时表 student 中的唯一一条数据符合 where id>=1 条件，因此会查询出来。然后根据 ReadView机制，发现该行数据的trx_id=10，小于事务 A 的 ReadView 里 up_limit_id，表示该数据在事务 A 开启之前就被提交了，因此事务 A 可以读取到。

步骤2：接着事务 B 往表中新插入两条数据，并提交事务。

insert into student(id,name) values(2,'李四'); 
insert into student(id,name) values(3,'王五');

此时表student 中就有三条数据了，对应的 undo 如下图所示：

image.png

步骤3：事务 A 第二次查询，并不会再重新生成ReadView。此时表 student 中的 3 条数据都满足 where id>=1 的条件，因此会先查出来。然后根据ReadView 机制，判断每条数据是不是都可以被事务 A 看到。

1） id=1 这条数据，前面已经判断过，可以被事务 A 看到。

2）id=2 的数据，它的 trx_id=30，此时事务 A 发现，这个值处于 up_limit_id 和 low_limit_id 之间，因此还需要再判断 30 是否处于 trx_ids 数组内。由于事务 A 的 trx_ids=[20,30]，因此在数组内，这表示 id=2 的这条数据是与事务 A 在同一时刻启动的其他事务提交的，所以这条数据不能让事务 A 看到。

3）id=3的数据同理

结论：最终事务 A 的第二次查询，只能查询出 id=1 的这条数据。这和事务 A 的第一次查询的结果是一样的，因此没有出现幻读现象，所以说在 MySQL 的可重复读隔离级别下，不存在幻读问题。

6. 总结

MVCC使不同事务的读-写、写-读操作并发执行，从而提升系统性能。

核心在于 ReadView 的原理，READ COMMITTD、REPEATABLE READ的一个大不同就是生成ReadView的时机不同：

  • READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView
  • REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都重复使用这个ReadView。

MVCC的作用：

  1. 读写之间阻塞的问题：MVCC可以让读写互相不阻塞，提升事务并发处理能力。
  2. 降低死锁的概率：MVCC采用了乐观锁的方式，读取数据时并不需要加锁写操作也只锁定必要的行。 3．解决快照读的问题：当我们查询数据库在某个时间点的快照时，只能看到这个时间点之前事务提交更新的结果，而不能看到这个时间点之后事务提交的更新结果。
avatar
文章
阅读
粉丝