事务都以读事务身份启动,读事务和只读事务会在需要时发生变化,它们会怎么变化?这是本文要回答的问题。
作者:操盛春,爱可生技术专家,公众号『一树一溪』作者,专注于研究 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
关键字,这个事务就是一个只读事务。例如:
SQL
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 审核和管理。支持主流的开源、商业、国产数据库,为开发和运维提供流程自动化能力,提升上线效率,提高数据质量。