事务都以读事务身份启动,读事务和只读事务会在需要时发生变化,它们会怎么变化?这是本文要回答的问题。

作者:操盛春,爱可生技术专家,公众号『一树一溪』作者,专注于研究 MySQL 和 OceanBase 源码。

爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。

本文基于 MySQL 8.0.32 源码,存储引擎为 InnoDB。

1. update、delete

后面小节的内容和 update、delete 有关,我们先简单介绍一下这两类 SQL 语句的执行流程。

以更新一条记录为例,update 语句的简化执行流程如下:

  • server 层要求 InnoDB 从表中读取一条记录。
  • InnoDB 返回记录之后,server 层判断这条记录是否匹配 where 条件。
  • 如果匹配,用 update 语句 set 子句中指定的各字段值,替换 InnoDB 返回记录的对应字段值。
  • 替换字段值得到完整记录之后,server 层触发 InnoDB 更新记录。

以删除一条记录为例,delete 语句的简化执行流程如下:

  • server 层要求 InnoDB 从表中读取一条记录。
  • InnoDB 返回记录之后,server 层判断这条记录是否匹配 where 条件。
  • 如果匹配,server 层触发 InnoDB 删除记录。

2. 读事务

上一期我们介绍过,事务真正启动于执行第一条 SQL 语句时,如果第一条 SQL 语句是 select、update、delete,事务会以读事务的身份启动。

读事务启动时,没有分配事务 ID 和回滚段,事务对象也没有加入到 trx_sys->rw_trx_list 链表。

根据我们使用 MySQL 的经验,以读事务身份启动的事务,不仅能正常执行改变(插入、更新、删除)表中数据的操作,还支持 MVCC、回滚。

对于启动时没有分配事务 ID 和回滚段的读事务来说,这是怎么做到的呢?

有一句话能够很好的回答这个问题,就是以发展的眼光看问题

以读事务身份启动的事务,并不意味着一直都是读事务,它可以在某些时间点变成读写事务

根据执行的第一条 SQL 语句不同,读事务变成读写事务的时间点可以分为两类:

第一类:第一条 SQL 语句是 update 或 delete。

在 update 或 delete 语句执行过程中,读事务就会变成读写事务。

发生变化的具体时间点,又取决于这两类 SQL 语句更新或删除记录的第一个表是什么类型。

如果第一个表是用户普通表,InnoDB 从表中读取一条记录之前,会给表加意向排他锁(IX)。

加意向排他锁时,如果以下三个条件成立,InnoDB 就会把这个事务变成读写事务:

  • 事务还没有为用户普通表分配回滚段。
  • 事务 ID 为 0,说明这个事务现在还是读事务。
  • 事务的只读标识 trx->read_only = false,说明这个事务可以变成读写事务。

读事务变成读写事务,InnoDB 主要做 3 件事:

  • 分配事务 ID。
  • 为用户普通表分配回滚段。
  • 把事务对象加入 trx_sys->rw_trx_list 链表。

如果第一个表是用户临时表,因为它的可见范围只限于创建这个表的数据库连接之内,其它数据库连接中执行的事务都看不到这个表,更不能改变表中的数据,所以,update、delete 语句改变用户临时表中的数据,不需要加意向排他锁。

读事务变成读写事务的操作会延迟到 server 层触发 InnoDB 更新或删除记录之后,InnoDB 执行更新或删除操作之前。

在这个时间节点,如果以下三个条件成立,InnoDB 就会把这个事务变成读写事务:

  • 事务已经启动了。
  • 事务 ID 为 0,说明这个事务现在还是读事务。
  • 事务的只读标识 trx->read_only = false,说明这个事务可以变成读写事务。

有一点需要说明,改变用户临时表的数据触发读事务变成读写事务,不会分配用户临时表回滚段,需要等到为某个用户临时表第一次写 Undo 日志时才分配。

第二类:第一条 SQL 语句是 select。

在 select 语句执行过程中,读事务不会变成读写事务;这条 SQL 语句执行完之后、事务提交之前,第一次执行 insert、update、delete 语句时,读事务才会变成读写事务。

一个读事务变成读写事务的操作,只会发生一次,发生变化的具体时间点,取决于最先碰到哪种 SQL 语句。

如果最先碰到 insert 语句,server 层准备好要插入的记录的每个字段之后,会触发 InnoDB 执行插入操作。

执行插入操作之前,如果以下三个条件成立,InnoDB 就会把这个事务变成读写事务:

  • 事务已经启动了。
  • 事务 ID 为 0,说明这个事务现在还是读事务。
  • 事务的只读标识 trx->read_only = false,说明这个事务可以变成读写事务。

如果最先碰到的是 update 或 delete 语句,读事务变成读写事务的具体时间点,参照第一类中关于用户普通表、用户临时表的介绍。

3. 只读事务

只读事务是读事务的特例,以 start transaction 开始一个事务时,如果包含了 read only 关键字,这个事务就是一个只读事务。例如:

start transaction read only

只读事务不能改变(插入、更新、删除)系统表、用户普通表的数据,但是能改变用户临时表的数据。

改变用户临时表的数据,同样需要为事务分配事务 ID,为用户临时表分配回滚段。根据只读事务执行的第一条 SQL 语句不同,这两个操作发生的时间点也可以分为两类。

第一类:第一条 SQL 语句是 update 或 delete。

在 update 或 delete 语句执行过程中,server 层触发 InnoDB 更新或删除记录之后,InnoDB 执行更新或删除操作之前,如果以下三个条件成立,InnoDB 就为这个事务分配事务 ID、为用户临时表分配回滚段:

  • 事务已经启动了。
  • 事务 ID 为 0。
  • 事务是个只读事务(trx->read_only = true)。

第二类:第一条 SQL 语句是 select。

在 select 语句执行过程中,不会分配事务 ID 和用户临时表的回滚段;这条 SQL 执行完之后、事务提交之前,第一次执行 insert、update、delete 语句时,才会执行这两个操作。

对于一个只读事务,这两个操作只会执行一次,执行的具体时间点,取决于最先碰到哪种 SQL 语句。

如果最先碰到 insert 语句,server 层准备好要插入的记录的每个字段之后,会触发 InnoDB 执行插入操作。

执行插入操作之前,如果以下三个条件成立,InnoDB 会为这个只读事务分配事务 ID、为用户临时表分配回滚段:

  • 事务已经启动了。
  • 事务 ID 为 0。
  • 事务是个只读事务(trx->read_only = true)。

如果最先碰到的是 update 或 delete 语句,执行这两个操作的具体时间点,参照第一类的介绍。

4. 总结

以读事务或只读事务身份启动的事务:

  • 如果执行的第一条 SQL 语句是 update 或 delete,在 SQL 语句执行过程中,读事务会变成读写事务,只读事务会分配事务 ID 和用户临时表的回滚段。
  • 如果执行的第一条 SQL 语句是 select,在后续第一次执行 insert、update、delete 三种语句的其中一种时,读事务会变成读写事务,只读事务会分配事务 ID 和用户临时表的回滚段。

读事务变成读写事务,InnoDB 主要做 3 件事:

  • 分配事务 ID。
  • 为用户普通表分配回滚段。
  • 把事务对象加入 trx_sys->rw_trx_list 链表。

本期问题:关于本期内容,如有问题,欢迎留言交流。

下期预告:MySQL 核心模块揭秘 | 06 期 | 事务提交之前,binlog 写到哪里?


操盛春

爱可生技术专家,公众号『一树一溪』作者,专注于研究 MySQL 和 OceanBase 源码。