深入浅出MySQL系列(3)—MVCC机制

最新推荐文章于 2024-07-25 11:20:42 发布

小李子i

最新推荐文章于 2024-07-25 11:20:42 发布

阅读量105

点赞数

文章标签： mysql 数据库

本文链接：https://blog.csdn.net/li2683056515/article/details/132249439

版权

5、InnoDB解决幻读（Next-Key锁+MVCC）

1、MVCC涵义，以及解决的问题

MVCC：MVCC 是通过数据行的多个版本管理来实现数据库的并发控制，简单来说它的思想就是保存数据的历史版本。这样我们就可以通过比较版本号决定数据是否显示出来，读取数据的时候不需要加锁也可以保证事务的隔离效果。

可以解决的问题： 可重复读级别下

①读写之间阻塞的问题，通过 MVCC 可以让读写互相不阻塞，即读不阻塞写，写不阻塞读，这样就可以提升事务并发处理能力。（写写之间还是会阻塞等待）

②降低了死锁的概率。这是因为 MVCC 采用了乐观锁的方式，读取数据时并不需要加锁，对于写操作，也只锁定必要的行。

③解决一致性读的问题。一致性读也被称为快照读，当我们查询数据库在某个时间点的快照时，只能看到这个时间点之前事务提交更新的结果，而不能看到这个时间点之后事务提交的更新结果。

2、快照读和当前读

快照读:快照读读取的是快照数据。不加锁的简单的 SELECT 都属于快照读

当前读:就是读取最新数据，而不是历史版本的数据。加锁的 SELECT，或者对数据进行增删改都会进行当前读

注意：快照读是不会产生幻读问题的；当前都才会出现幻读的问题；

3、事务启动方式

①begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动（一致性视图是在第执行第一个快照读语句时创建的）

②start transaction with consistent snapshot 可以立马启动一个事务。（一致性视图是在执行 start transaction with consistent snapshot 时创建的）

视图：（MySQL中的两种视图）

①一个是 view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是 create view … ，而它的查询方法与表一样。

②另一个是 InnoDB 在实现 MVCC 时用到的一致性读视图，即 consistent read view，用于支持 RC（Read Committed，读提交）和 RR（Repeatable Read，可重复读）隔离级别的实现。

4、MVCC实现逻辑

在可重复读隔离级别下，事务在启动的时候就“拍了个快照”

每个事务都有一个事务ID，叫做transaction id(严格递增)
每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID，记为 row trx_id。

数据表中的一行记录，其实可能有多个版本 (row)，每个版本有自己的 row trx_id。

上述图中的三个虚线箭头就是回滚日志undo log；而 V1、V2、V3 并不是物理上真实存在的，而是每次需要的时候根据当前版本和 undo log 计算出来的。

具体实现：

InnoDB 为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务 ID。“活跃”指的就是，启动了但还没提交。

数组里面事务 ID 的最小值记为低水位，当前系统里面已经创建过的事务 ID 的最大值加 1 记为高水位。
这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。

而我们需要拿row trx_id和这个视图作比较：

①如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的；

②如果落在红色部分，表示这个版本是由将来启动的事务生成的，是不可见的

③如果落在黄色部分，那就包括两种情况 a. 若 row trx_id 在数组中，表示这个版本是由还没提交的事务生成的，不可见； b. 若 row trx_id 不在数组中，表示这个版本是已经提交了的事务生成的，可见。

注意：

1）更新操作的逻辑：

规则：更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。

更新时，如果当前的记录行锁被其它事务占用的话，就需要进入锁等待！

2）对于自己事务中的更新操作是需要认的！！

3）可重复读和读提交的实现逻辑：

可重复读在事务开始的时候创建一致性视图；而读提交，每个语句执行前都会创建新的视图；