隐式锁就像是口头协议,这种口头协议怎么落到实处起作用?

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

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

1. 什么是隐式锁?

前面我们介绍了行锁的共享锁、排他锁。按照精确模式,它们又都可以细分为普通记录锁、间隙锁、Next-Key 锁。

另外,还有一种专门用于插入记录场景的插入意向锁。

事务读写记录需要加这些行锁时,会发起加锁操作,申请新的行锁结构或者复用已有的行锁结构。

有了对应的行锁结构,我们就可以通过 performance_schema.data_locks 表查询到这些行锁的加锁情况了。InnoDB 内部把这种有对应锁结构的行锁称为显式锁。

隐式锁,是相对于显式锁而言的,它也是一种行锁,而且是普通记录锁的一种特殊存在形式。

顾名思义,既然是隐式锁,也就意味着我们查询不到它的加锁情况。

我们之所以查询不到,是因为隐式锁没有对应的行锁结构,它就像空气一样,神在,形不在。

我们知道空气是存在的,通常情况下,我们看不见,也摸不着。但是,热空气遇冷之后,凝结成小水珠,我们就能看得见,也能摸得着了。

我们也知道隐式锁是存在的,却查询不到。它也会像空气一样,有被看见的时候吗?

是的,它也有被看见的时候。但是,当它被看见的时候,已经换了一种形式,不再是隐式锁了,而是变成了显式锁。

隐式锁变成显式锁之后,我们就可以通过 performance_schema.data_locks 表查询到加锁情况了。

那么,问题来了,隐式锁到底是被看见了,还是没有被看见呢?

2. 怎么判断存在隐式锁?

隐式锁,不仅可以存在于主键索引记录上,还可以存在于二级索引记录上。

在它变成显式锁之前,我们怎么判断一条记录上是否存在隐式锁呢?

我根据代码逻辑归纳了四种情况。

情况 1,事务执行 insert 语句或者 update 语句插入一条记录到主键索引中,事务提交之前,这条记录上存在隐式锁。

update 语句不是更新记录吗,怎么还会插入记录?

如果你也有这样的疑问,说明这是个好问题。

有一种场景:如果 update 语句更新了主键字段值,主键索引的原记录会被标记删除,然后插入一条新记录。

其中,原记录的主键字段为更新之前的值,新记录的主键字段为更新之后的值。

情况 2,事务执行 insert 语句插入一条记录到二级索引中,事务提交之前,这条记录上存在隐式锁。

情况 3,事务执行 update 语句更新了二级索引的某个字段,二级索引的原记录会被标记删除,然后插入一条新记录,事务提交之前,原记录和新记录上都存在隐式锁。

情况 4,事务执行 delete 语句,如果扫描记录时没有使用二级索引,二级索引记录不会被显式加锁。

二级索引记录被标记删除之后,事务提交之前,记录上都存在隐式锁。

根据代码逻辑归纳出所有情况是很困难的,为了帮助我们更好的判断记录上是否存在隐式锁,我们有必要看看 InnoDB 代码里的判断逻辑长什么样。

InnoDB 代码里,判断记录上是否存在隐式锁的逻辑,和索引类型有关。

对于主键索引,判断逻辑比较简单。

InnoDB 会从主键索引记录的 DB_TRX_ID 字段中读取事务 ID,找到最后操作这条记录的事务。

只要主键索引记录上没有显式锁,并且最后操作记录的事务还没有提交,就认为这条记录上存在隐式锁。

对于二级索引,因为索引记录中没有 DB_TRX_ID 字段,判断逻辑会比主键索引复杂一点。

二级索引数据页的头信息中有个 PAGE_MAX_TRX_ID 字段,表示最后修改数据页中任意一条记录的事务 ID。

以某个二级索引中的一条记录(S1)为例,判断这条记录上是否存在隐式锁的主要步骤如下:

第 1 步,读取 S1 所属数据页头信息中的 PAGE_MAX_TRX_ID 字段,看看这个事务 ID 对应的事务是否已经提交了。

如果事务已经提交,说明 S1 上不存在隐式锁。

如果事务还没有提交,进入第 2 步

第 2 步,根据 S1 中的主键字段,回表查询对应的主键索引记录。

找到主键索引记录之后,从它的 DB_TRX_ID 字段中读取事务 ID,看看这个事务 ID 对应的事务是否已经提交了。

如果事务已经提交,说明 S1 上不存在隐式锁。

如果事务还没有提交,那就麻烦了,需要进一步判断,这个代码逻辑就很晦涩了。

不过,值得欣慰的是,虽然代码逻辑很晦涩,但是用大白话描述起来可以很简单。

用大白话描述是这样的:只要这个还没有提交的事务操作过 S1,不管这个操作是插入,还是删除,都意味着 S1 上存在隐式锁。

3. 转换为显式锁

如果某条记录上存在隐式锁,在需要时,会被转换被显式锁。这个转换主要发生在两种场景下。

场景一,记录(R1)上存在隐式锁,其它事务(A)读写 R1 之前,如果需要对 R1 加行锁,事务 A 会把 R1 上的隐式锁转换为显式锁,然后等待 R1 上的行锁被释放之后,事务 A 才能获得锁。

场景二,某个事务部分回滚时,如果它操作过的记录上存在隐式锁,会被转换为显式锁。

部分回滚,指的是把事务回滚到某个保存点。这个保存点可以是我们手动创建的保存点,也可以是 InnoDB 内部创建的保存点。

InnoDB 内部创建的保存点,主要用于插入记录出现冲突时,回滚已经执行的操作。

介绍完隐式锁转换为显式锁的场景,我们再来看看隐式锁会被转换成什么样的显式锁。

前面我们介绍过,隐式锁是普通记录锁的一种特殊存在形式,所以,它也是普通记录锁。

隐式锁,既可以存在于刚刚插入的记录上,也可以存在于标记删除的二级索引记录上,所以,它又是一种排他锁。

两者综合起来,隐式锁本质上相当于排他普通记录锁。

发生转换时,隐式锁会被转换为排他普通记录锁。这个转换逻辑是不是又简单又粗暴?

4. 总结

隐式锁,是排他普通记录锁的一种特殊存在形式。

我们查询不到隐式锁的加锁情况,只能根据我们的经验判断记录上是否存在隐式锁。

在某些场景下,隐式锁会被转换为显式锁,然后,我们就可以通过 performance_schema.data_locks 表查询到加锁情况了。


操盛春

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