MySQL学习-7|事务隔离：事务到底是隔离的还是不隔离的？

事务简述

环境： MySQL 5.7.24, for linux-glibc2.12 (x86_64)

• 简单来说，事务就是要保证 一组 数据库操作，要么全部成功，要么全部失败。
• ACID(Atomicity 原子性、Consistency 一致性、Isolation 隔离性、Durability 持久性)
• 事务支持是在存储引擎层¹实现的。 InnoDB 引擎支持事务，而MyISAM引擎不支持事务。

-- 查看使用的引擎信息
show engines;

隔离级别	特点
读未提交	一个事务还没提交时，它所做的变更就已经能被其他事务看到
读提交	一个事务提交之后，它所做的变更才能被其他事务看到
可重复读	一个事务执行过程中看到的数据，总是跟它在启动时所看到的数据是一致的。未提交的变更，对其他事务不可见
串行化	对于同一行记录，“写"会加"写锁”，“读"会加"读锁”。出现读写锁冲突时，后访问的事务必须等待前一个事务执行完成，才能继续执行

mysql> show variables like 'transaction_isolation';
+-----------------------+----------------+
| Variable_name         | Value          |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
+-----------------------+----------------+

示例分析

-- CREATE
mysql> CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `k` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

-- INSERT
insert into t(id, k) values(1,1),(2,2);

• 启动3个事务：A、B、C，按照以下步骤操作，查询的k值是多少？默认autocommit=1。

步骤	事务A	事务B	事务C
1	start transaction with consistent snapshot;
2		start transaction with consistent snapshot;
3			update t set k=k+1 where id=1;
4		update t set k=k+1 where id=1;
5		select k from t where id=1;
6	select k from t where id=1;
7	commit;
8		commit;

• begin/start transaction命令并不是一个事务的起点，在执行到它们之后的第一个操作InnoDB表的语句，事务才真正启动。
• 如果想要马上启动事务，可以使用start transaction with consistent snapshot这个命令。

begin/start transaction方式，一致性视图是在执行第一个快照语句时创建；

马上启动事务方式，一致性视图是在执行start transaction with consistent snapshot;时创建。

• 事务C没有显式地使用begin/commit，表示这个update语句本身就是一个事务，语句在完成时会自动提交（默认autocommit=1）；
• 事务B在更新了行记录之后查询；(k=3)
• 事务A在一个只读事务中查询，并且时间顺序上是在事务B的查询之后；(k=1)

视图

在MySQL中，视图 有两种概念。

• 一个是view， 是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是create view ...，查询视图的方法与查询表一样。
• 另一个是InnoDB在实现多版本并发控制(MVCC)时用到的一致性视图，即consistent read view，用于支持RC(Read Commited，读提交)和RR(Repeatable Read，可重复读)隔离级别的实现。它没有物理结构，作用是事务执行期间用来定义"我能看到什么数据"。

快照

在RR(Repeatable Read，可重复读)隔离级别下，事务在启动的时候就"拍了个快照"，这个快照是基于整库的。

InnoDB里每个事务都有一个唯一的事务ID，叫做transaction id，是在事务开始的时候向InnoDB的事务系统申请的，按照申请顺序严格递增。

每行数据也都是有多个版本的。每次事务更新数据时，都会生成一个新的数据版本，并且把transaction id赋值给这个数据版本的事务ID，记为row trx_id。同时旧的数据版本要保留，并在新的数据版本中，能够有信息可以直接拿到它。
即，数据表的一行记录，其实可能有多个版本(row)，每个版本有自己的row trx_id。

下图为行状态变更图，虚线框中是同一行数据的4个版本，最新版本是V4，k=22，是被transaction id为25的事务更新的，因此它的row trx_id也是25。

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

• 按照可重复读的定义，一个事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见。
• 因此，一个事务只需要在启动时声明，以我启动的时刻为准，如果一个数据版本是在我启动之前生成的，就认；如果是我启动以后才生成的，就不认，我必须要找到它的上一个版本。
• 如果上一个版本也不可见，那就继续往前找。另外，如果是这个事务自己更新的数据，它自己还是要认的。

在实现上，InnoDB为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在活跃（启动了但还没提交）的所有事务ID。

数组里面事务ID的最小值记为低水位，当前系统里已经创建过的事务ID的最大值加1记为高水位。

这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。
数据版本的可见性规则，就是基于数据的row trx_id和这个一致性视图的对比结果得到的。

对于当前事务的启动瞬间来说，一个数据版本的row trx_id，有以下几种可能：

• 1、如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的。
• 2、如果落在红色部分，表示这个版本是由将来启动的事务生成的，不可见。
• 3、如果落在黄色部分，那就包括两种情况：
• 3.1) 若row trx_id在数组中，表示这个版本是由还没提交的事务生成的，不可见；
• 3.2) 若row trx_id不在数组中，表示这个版本是由已经提交的事务生成的，可见。

InnoDB利用了所有数据都有多个版本这个特性，实现了秒级创建快照的能力。

解析示例

解析在上面的示例中，事务A的语句返回结果k=1？

这里，我们不妨做如下假设：
1、事务A开始前，系统里只有一个活跃事务ID是99；
2、事务A、B、C的版本号分别是100.101.102，且当前系统里只有这四个事务；
3、三个事务开始前，(1,1)这一行数据的row trx_id是90。

这样，事务A的视图数组就是[99,100]，事务B的视图数组就是[99,100,101]，事务C的视图数组就是[99,100,101,102]。

事务A查询数据逻辑图：

在上图中，第一个有效更新的事务C，把数据从(1,1)改成了(1,2)。这时，这个数据的最新版本的row trx_id是102，而90这个版本已经成为了历史版本。

第二个有效更新的事务B，把数据从(1,2)改成了(1,3)。这时，这个数据的最新版本的row trx_id是101，而102这个版本又成为了历史版本。

在事务A查询的时候，其实事务B还没提交，但它生成的(1,3)这个版本已经变成当前版本了，但是这个版本对事务A必须是不可见的，否则就变成脏读了。

事务A来读数据，它的视图数组是[99,100]。当日了，读数据都是从当前版本读起的，所以事务A查询语句读数据的流程如下：

• 找到(1,3)的时候，判断出row trx_id=101，比高水位大，处于红色区域，不可见；
• 接着找到上一个历史版本，判断出row trx_id=102，比高水位大，处于红色区域，不可见；
• 再往前找，找到(1,1)，判断出row trx_id=90，比低水位还小，处于绿色区域，可见；

版本未提交，不可见
版本已提交，但是在视图创建后提交的，不可见
版本已提交，且是在视图创建前提交的，可见。

更新逻辑
事务B的update语句，如果按照一致性读，好像结果不对？

事务B更新逻辑：

如果事务B在更新之前，查询一次数据k，这时查询返回的k确实是1。但是，当它要去更新数据时，就不能再在历史版本上更新了，否则事务C的更新就丢失了。
因此，事务B的set k=k+1是在(1,2)的基础上进行的操作。

这里就用到了这样一条规则：更新数据都是先读后写的，而这个读，只能读当前的值，称为当前读(current read)。

• 在更新的时候，当前读拿到的数据是(1,2)，更新后生成新版本的数据(1,3)，这个新版本的row trx_id=101；
• 所以，事务B的查询语句，一看自己的row trx_id=101，而最新数据的row trx_id=101，可以直接使用，所以k=3.

除了update语句外，select语句如果加锁，也是当前读。

-- 读锁(S锁, 共享锁)
mysql> select k from t where id=1 lock in share mode;

-- 写锁(X锁, 排他锁)
mysql> select k from t where id=1 for update;

启动3个事务：A、B、C’，按照以下步骤操作，会怎样呢？

步骤	事务A	事务B	事务C’
1	start transaction with consistent snapshot;
2		start transaction with consistent snapshot;
3			start transaction with consistent snapshot;
4			update t set k=k+1 where id=1;
5		update t set k=k+1 where id=1;
6		select k from t where id=1;
7	select k from t where id=1;		commit;
8	commit;
9		commit;

事务C’与上面的事务C不同，显式使用begin/commit，所以在update后并没有马上提交，在它提交之前，事务B的更新语句执行了。
这时，虽然事务C’还没提交，但是(1,2)这个版本已经生成，并且是当前的最新版本，这个版本上的写锁还没释放。事务B是当前读，必须要读最新版本，而且必须加锁，因此就被锁住了，必须要等事务C’释放写锁，才能继续它的当前读。

事务B更新逻辑（配合事务C’）：

这样就把一致性读、当前读、行锁串起来了。

事务的可重复读能力是怎么实现的？

• 可重复读的核心就是一致性读(consistent read)；
• 事务更新数据时，只能用当前读；如果当前记录的行锁被其他锁雾占用，就需要进入锁等待。

读提交的逻辑和可重复读的逻辑类似，主要区别是：

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

在读提交隔离级别下，事务A和事务B的查询语句返回的k分别是多少呢？
start transaction with consistent snapshot;的意思是从这个语句开始，创建一个持续整个事务的一致性快照。所以，在读提交隔离级别下，这个用法就没有意义了，等效于普通的start transaction。

读提交隔离级别下的事务状态图（这里用的是事务C的逻辑直接提交，而不是C’）：

事务A的查询语句的视图数组是在执行select语句时创建，时序上(1,2), (1,3)的生成时间都在创建这个视图数组的时刻之前，但是这个时刻：
(1,3)还没提交，属于情况1，不可见；
(1,2)提交了，属于情况3，可见。

所以，事务A查询语句返回k=2；事务B查询结果k=3。

参考资料

《高性能MySQL》
《MySQL实战45讲》 作者：丁奇

写在后面

之前学习了大神丁奇的《MySQL实战45讲》，目前在看《高性能高MySQL》，也想自己整理一下MySQL知识点，发现力不从心，也发现大神之所以是大神，那是因为真的牛。

推荐大家还是去学习丁奇的《MySQL实战45讲》，条理清晰，循序渐进，深入浅出，通俗易懂。而且每一讲后面都有高质量的留言评论， 从中能获益良多。感谢！

• 如有 错误之处 还请多多指正。希望能给您带来帮助。

---

1. MySQL基础架构 ↩︎