事务都以读事务身份启动，读事务和只读事务会在需要时发生变化，它们会怎么变化？这是本文要回答的问题。
作者：操盛春，爱可生技术专家，公众号『一树一溪』作者，专注于研究 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 写到哪里？