微信号:yogoup

介绍:网站性能提升与架构设计

分析一个MySQL并发事务示例

2019-01-12 09:00 性能与架构

示例

有这样一张表:

现在有3个事务 A B C 并发执行:

事务A、事务B的select的结果是什么呢?

使用 ”start transaction with consistent snapshot;“ 语句的目的是马上启动事务,”begin/start transaction“命令不是一个事务的起点,而是在执行到他们之后的第一个操作 InnoDB 表的语句后事务才开始。

下面我们实际执行以下看看结果,先建表插入数据:

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

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

然后开3个mysql client终端,分别代表 A B C,执行:

# client A
start transaction with consistent snapshot;

# client B
start transaction with consistent snapshot;

# client C
update t set k=k+1 where id=1;

# client B
update t set k=k+1 where id=1;
select k from t where id=1; # 3

# client A
select k from t where id=1; # 1
commit;

# client B
commit;

结果:

  • 事务B的select语句结果是 3

  • 事务A的结果是 1

如果你猜对了,也知道是为什么,可以休息了 : ),如果没猜对,那么咱们就一起分析一下。

分析

1. 背景知识

MySQL 默认的事务隔离级别是可重复读,事务在启动时给整个库拍了个快照。

如果一个库有100G,那快照多慢啊,实际快照不是做数据复制,而是基于数据版本日志。

InnoDB里每个事务都有一个唯一的事务ID(transaction id),事务启动时申请,按申请顺序严格递增

每行数据是有多个版本的,每次事务更新数据的时候,都会生成一个新的版本,并且记录上这个版本是哪个事务ID干的。所以,每行记录都可能有多个版本,每个版本有自己的 row trx_id

虚线中是同一行数据的4个版本,当前最新版本是 V4,k 值为22,是ID为25的事务更新的。V1 V2 V3 并不是物理存在的,需要的时候可以通过当前版本和 undo log 计算出来。

根据”可重复读“的定义,一个事务启动时,能够看到所有已经提交的事务的结果,事务执行期间,其他事务的更新就不可见了。

所以,就相当于一个事务启动时发出声明:”以我启动时间为准,我只认启动之前的数据版本,如果是我启动之后生成的,我就找之前的数据版本,直到我认可的版本“。

InnoDB 会为每个事务构造一个数组,用来保存在这个事务启动的瞬间正在活跃(已启动但还未提交)的所有事务ID。

例如 transaction id 为 15 的事务启动时,还有事务9、事务12 活跃,那么事务15就有一个数组:[9,12,15],通过这个数组我们可以明确几件事:

  1. < 9 的事件肯定都可见,因为都已经执行完成了。

  2. > 15 的事件肯定都不可见,因为这些事件是后来的。

  3. 这个数组中,除了自己以为的其他事务的更改结果肯定是不可见的,因为他们在我启动的时候还没提交呢。

  4. > 9 并且 < 15 的事件中,不在这个数组中的,肯定是可见的,因为他们在我启动时都提交完成了,例如事务10,ID小于我(15),而且在我启动时不是活跃的,说明执行完成了,那么对我来讲他就是可见的。

所以,我们现在知道了,InnoDB 利用 所有数据都有多个版本 这个特性,实现了秒建快照的能力。

2. 示例分析

现在我们回到之前的示例,看看执行过程。

假设:

  1. 事务A 开始前,只有一个活跃事务 99

  2. 事务 A B C 的版本号是 100、101、102,当前系统只有这4个事务

  3. 3个事务开始之前,(1,1)这行数据的 row trx_id = 90

这样,视图数组如下:

  • 事务A -> [99, 100]

  • 事务B -> [99, 100, 101]

  • 事务C -> [99, 100, 101, 102]

2.1事务A的逻辑

第一个有效更新时事务C,这个数据的最新版本的 row trx_id 是 102,90 那个版本成为了历史版本。

第二个有效更新时事务B,这个数据的最新版本的 row trx_id 变成了 101。

然后事务A来读数据了,他的视图数组是 [99,100],事务A的读取流程是这样的:

  • 找到当前版本,一看 row trx_id = 101,比自己视图数组的最大值还大,不可见

  • 接着找上一个版本,一看 row trx_id = 102,还是不可见

  • 再找上一个版本,row trx_id = 90,比自己视图数组的最小值还小,终于可见了

所以,事务A的查询结果就是 1

2.2 事务B的逻辑

对于事务B,我们会有一个疑问,根据一致性读规则,结果不对啊,事务B的视图数组是先生成的,事务C后提交的,事务B执行 update 时,不是应该基于 (1,1)吗?怎么会基于(1,2)呢?

这涉及到另一个原则:更新数据时要先读后写,此时读的是”当前版本“,称为 ”当前读(current read)“。

因为更新数据时不能再在历史版本上更新,否则事务C的更新就丢失了,所以事务B的 update 是在(1,2)基础上操作的。

事务B执行 select 时,一看数据的当前版本是 101,是自己更新的,可以直接使用,所以查询结果就是 3 了。

总结

可重复读隔离级别的核心:

  • 读数据是一致性读

  • 更新数据是当前读

  • 如果当前记录的行锁被其他事务占用,进入等锁状态

内容整理自阿里技术专家丁奇的专栏《MySQL实战45讲》


 
性能与架构 更多文章 快速理解 MySQL 事务隔离级别 MySQL中一条SQL语句是如何执行的? 最新腾讯+阿里+百度面试指南,必须要掌握这6大知识点(跳槽必看) 使用有颜色的 Console 信息 Medium 微服务策略
猜您喜欢 [广州][2016.05.07] 第一届 Appium Girls 开始报名啦!!! 设计模式在游戏开发中的应用之命令模式 四个男人一台戏 技术漫谈 | kubernetes1.9源码阅读 kubelet对pod资源的watch 成功的程序员是这样的