MySQL 核心模块揭秘 | 05 期 | 读事务和只读事务的变形记

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

作者：操盛春，爱可生技术专家，公众号『一树一溪』作者，专注于研究 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 写到哪里？

更多技术文章，请访问：opensource.actionsky.com/

关于 SQLE

SQLE 是一款全方位的 SQL 质量管理平台，覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库，为开发和运维提供流程自动化能力，提升上线效率，提高数据质量。