【mysql】事务隔离的原理剖析

【mysql】事务隔离的原理剖析

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

​​前言​​​​事务的启动时机与一致性视图的创建时机​​​​Mysql的两种视图概念​​​​“快照”在 MVCC 里的工作原理​​​​事务查询逻辑（可重复读隔离级别）​​​​事务更新逻辑（可重复读隔离级别）​​​​总结​​

前言

如果是可重复读隔离级别，事务 T 启动的时候会创建一个视图 read-view（又称一致性视图），之后事务 T 执行期间，即使有其他事务修改了数据，事务 T 看到的仍然跟在启动时看到的一样。

事务的启动时机与一致性视图的创建时机

（1）第一种启动方式：begin/start transaction + 执行第一个操作 InnoDB 表的语句（增删改查均可） begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动。而一致性视图是在执行第一个快照读（select）语句时创建的；

（2）第二种启动方式： start transaction with consistent snapshot 这个命令 执行完start transaction with consistent snapshot 事务马上开启，而一致性视图也会在命令执行时创建

Mysql的两种视图概念

一个是 view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是 create view … ，而它的查询方法与表一样。view视图有物理结构 另一个是 InnoDB 在实现 MVCC 时用到的一致性读视图，即 consistent read view，用于支持 RC（Read Committed，读提交）和 RR（Repeatable Read，可重复读）隔离级别的实现。一致性视图没有物理结构，一致性视图通过高低水位，数据版本号，undo log来进行判断数据可见不可见

“快照”在 MVCC 里的工作原理

“可重复读”隔离级别下，事务在启动时“拍了个快照”。注意，这个快照是基于整库的。 “读已提交”隔离级别下，事务在启动时“拍了个快照”。但这个视图是在每个 SQL 语句开始执行的时候创建的。

事务ID概念 InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。它是在事务启动时（不一定是创建的时候，如begin/start transaction，是没有申请事务id的）向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。

图中虚线框里是同一行数据的 4 个版本，当前最新版本是 V4，k 的值是 22，它是被 transaction id 为 25 的事务更新的，因此它的 row trx_id 也是 25。 图 2 中的三个虚线箭头，就是 undo log；而 V1、V2、V3 并不是物理上真实存在的，而是每次需要的时候根据当前版本和 undo log 计算出来的。比如，需要 V2 的时候，就是通过 V4 依次执行 U3、U2 算出来。

InnoDB 定义快照原理

在可重复读隔离级别下，事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见，需要找到可见的版本（或者事务自己更新的版本）。

事务可见性实现规则

在实现上， InnoDB 为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务 ID（实现上不包括当前启动的事务）。“活跃”指的就是，启动了但还没提交。 数组里面事务 ID 的最小值记为低水位，当前系统里面已经创建过的事务 ID的最大值加 1 记为高水位。(PS:如在事务A启动瞬间，再计算高水位，创建数组。高水位不一定是事务A的id+1)。举例如下：

#情况1假设 ：目前正在活跃事务id为991. 事务A启动，申请到trx_id 1004. 计算高水位（等于99+1），事务A创建视图数组 [99] （实现上,事务启动瞬间，视图数组不包含自己的事务id，文章原作者这里[99，100] ，不重要，因为事务A自己的更新总是可见）#情况2假设 ：目前正在活跃事务id为991. 事务A启动，申请到trx_id 1002. 事务B启动，申请到 trx_id 1013. 事务C启动，申请到 trx_id 1024. 计算高水位（等于102+1），事务A创建视图数组 [99，100，101，102]

如果落在绿色部分（低于低水位），表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的；如果落在红色部分（高于高水位），表示这个版本是由将来启动的事务生成的，是肯定不可见的；如果落在黄色部分，那就包括两种情况： a. 若 row trx_id 在数组中，表示这个版本是由还没提交的事务生成的，不可见； b. 若 row trx_id 不在数组中，表示这个版本是已经提交了的事务生成的，可见。

事务可见性规则总结

一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况： 版本未提交，不可见； 版本已提交，但是是在视图创建后提交的，不可见； 版本已提交，而且是在视图创建前提交的，可见。

事务查询逻辑（可重复读隔离级别）

事务更新逻辑（可重复读隔离级别）

mysql> select k from t where id=1 lock in share mode; //加了读锁（S 锁，共享锁）mysql> select k from t where id=1 for update; //写锁（X 锁，排他锁）

事务的可重复读的能力是怎么实现的？可重复读的核心就是一致性读（consistent read）； 而事务更新数据的时候，只能用当前读。 如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。而读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：

在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图；在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。

这里需要说明一下，“start transaction with consistent snapshot; ”的意思是从这个语句开始，创建一个持续整个事务的一致性快照。所以，在读提交隔离级别下，这个用法就没意义了，等效于普通的 start transaction

总结

小结InnoDB 的行数据有多个版本，每个数据版本有自己的 row trx_id，每个事务或者语句有自己的一致性视图。普通查询语句是一致性读，一致性读会根据 row trx_id 和一致性视图确定数据版本的可见性。

对于可重复读，查询只承认在事务启动前就已经提交完成的数据；对于读提交，查询只承认在语句启动前就已经提交完成的数据；而当前读，总是读取已经提交完成的最新版本。

你也可以想一下，为什么表结构不支持“可重复读”？这是因为表结构没有对应的行数据，也没有 row trx_id，因此只能遵循当前读的逻辑。

当然，MySQL 8.0 已经可以把表结构放在 InnoDB 字典里了，也许以后会支持表结构的可重复读。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。