【MySQL】MVCC详解, 图文并茂简单易懂

在这里插入图片描述

欢迎来到啊妮莫的学习小屋

祝读本文的朋友都天天开心呀

MVCC简介

MVCC也称: 多版本并发控制. 顾名思义, MVCC是通过数据行的多个版本管理来实现数据库的并发控制. MVCC使得在InnoDB的事务隔离级别下, 执行一致性读操作有了保证. 简单来说就是: 在需要读取一些正在被另一个事务更新的行数据时, 读取之前的历史版本数据(旧数据); 而不需要等待另一个事务释放锁.

并不是所有的存储引擎都支持MVCC技术, 本文讲解的是MySQL中InnoDB存储引擎下的MVCC机制.

快照读与当前读

MVCC机制主要解决的是读--写冲突问题, 提高数据库的并发性能.

当发生读写冲突时:

读采用快照读, 不加锁非阻塞并发读

写采用当前读, 加锁

MVCC机制本质上是采用了乐观锁思想

快照读

又名一致性读, 读取到的是快照数据. 不加锁的简单SELECT都是快照读.

例如:

SELECT * FROM student WHERE...

快照读可能读到的并不一定是数据的最新版本, 而有可能是之前的历史版本.

快照读可以形象的理解为我们生活中的照片, 拍摄到的画面都是过去式.

在这里插入图片描述

当前读

当前读读取到的是 最新版本数据.

读取时需要保证其他并发事务不能修改当前记录, 因此需要加锁.

例如:

SELECT * FROM student LOCK IN SHARE MODE;    # 共享锁

SELECT * FROM student FOR UPDATE;    # 排他锁

-- 修改操作对应的排他锁
INSERT INTO student VALUES ...    
DELETE FROM student WHERE ...
UPDATE student SET ...

当前读可以形象的理解为生活中的直播, 看到到的画面是实时的, 最新的.

在这里插入图片描述

隔离级别

事务有四种隔离级别: 读未提交, 读已提交, 可重复读, 串行化.

读未提交: 其他事务可以看见未提交事务做出的数据改变. 也就是会发生脏读.
读已提交: 其他事务只能看到已经提交事务做出的数据改变. 若另一个事务不断的更新某一行数据并提交, 那么读取出来的数据前后不一致, 即不可重复读.
可重复读: 解决了不可重复读问题, 确保同一事务多次读取结果一致. 但是依然会发生幻读问题–另一个事务插入新的数据行, 那么读取该范围内的数据时, 会发现新的"幻影"行.
串行化: 最严格的隔离级别, 通过加锁避免了脏读, 不可重复读和幻读, 但是性能较差.

在这里插入图片描述

MySQL的默认隔离级别是可重复读
可重复读隔离级别解决了脏读和不可重复读问题, 未解决幻读问题.

但是, MySQL中的MVCC机制解决了幻读问题! 它可以在大多数情况下代替行级锁, 提高数据库的事务并发能力.

在这里插入图片描述

隐藏字段和Undo Log版本链✨

对于使用InnoDB存储引擎的表来说, 其聚簇索引中的行数据包含了三个隐藏字段: row_id, trx_id, roll_pointer.

其中trx_id和roll_pointer使得用户记录生成一条Undo Log版本链.

trx_id: 这个字段记录了最后修改行记录的事务ID.
roll_pointer: 这个字段是一个指针, 指向该行记录的回滚段, 在发生事务回滚时用来撤销行记录的修改.

例如: students的表数据如下

mysql> SELECT * FROM students WHERE id=1;
+------+----------+----------+
| id   | stu_name | major    |
+------+----------+----------+
|    1 | 张三     | 软件工程 |
+------+----------+----------+
1 row in set (0.00 sec)

假设插入该记录的事务ID等于8, 则该条记录的示意图如下所示:

在这里插入图片描述

🌈

注意: insert undo只在事务回滚起作用, 当事务提交后, 该类型的undo日志就没有用了, 它占用的UndoLog Segment也会被系统回收(也就是该undo日志占用的Undo页面链表要么被重用, 要么被释放).

假设之后两个事务ID分别为10, 20的事务对该条数据进行UPDATE操作, 操作流程如下:

在这里插入图片描述

🌈

注意: 不能两个事务交叉更新同一条数据! 即: 一个事务修改另一个未提交的事务修改过的数据 (脏写).

InnoDB使用锁来保证不会有脏写的情况发生: 当一个事务更新了某条记录后, 会给这条记录加锁; 另一个事务需要等待锁被释放后才可以更新.

每次修改, 都会记录一条undo日志, 每一条undo日志也都会有一个roll_pointer字段, 将这些undo日志串成一个链表–Undo Log 版本链

在这里插入图片描述

Undo Log 版本链的头结点就是当前的最新记录. 所有版本依靠roll_ptr字段连接成一个链表.

MVCC原理–ReadView✨

MVCC的实现依赖于: 两个隐藏字段, Undo Log, ReadView.

在这里插入图片描述

ReadView简介

ReadView就是事务在使用MVCC机制进行快照读操作时产生的读视图.

当事务读取数据时, 会数据库系统生成当前的一个快照, InnoDb会为事务构造一个数组, 用于记录并维护系统中当前的活跃事务ID组(活跃是指: 开启了但是还没有进行提交).

设计思路

适用隔离级别

ReadView仅仅适用于读已提交和可重复读隔离级别, 对于这两种隔离级别, 都必须保证读到的是已经提交的事务修改过的记录. 假如另一个事务已经修改但是还没有提交, 是不能直接读取到的. 核心问题是判断版本链中哪些版本记录是当前事务可见的,这是ReadView要解决的主要问题.

对于读未提交: 读到的就是最新版本数据.

对于串行化: 事务排队执行, InnoDB使用锁机制来避免读写冲突.

重要内容

creator_trx_id: 创建这个ReadView的事务ID.
trx_ids: 在生成ReadView时, 当前系统中活跃的读写事务的ID列表.
up_limit_id: 活跃的事务中最小的事务ID.
low_limit_id: 表示在生成ReadView时系统应该分配给下一个事务的ID, 也就是系统中最大的事务ID值.

🌈

注意: 对于只读事务, creator_trx_id 默认为0

举例:
若现有id为1, 2, 3这三个事务, 之后id=3的事务提交了;
那么一个新的读事务在生成ReadView的时, trx_ids=[1,2], up_limit_id=1, low_limit_id的值为4

在这里插入图片描述

ReadView规则

当需要读取某条记录的时候, 只需要按照以下步骤就可以判断该记录的某个版本是否可见.

当读取版本的trx_id=creator_trx_id, 也就是当前事务修改过的记录–可见.
trx_id<up_limit_id, 该版本的事务已经在生成ReadView之前就提交了–可见.
trx_id>=low_limit_id, 该版本的事务是在生成ReadView之后才开启的–不可见.
up_limit_id<=trx_id<low_limit_id, 则需要分情况讨论
- 不在trx_ids列表中, 说明该事务已经提交–可见.
- 在列表中, 该事务在生成ReadView时处于活跃状态–不可见.