一文弄懂 MySQL 中的隐式锁

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

作者：操盛春，爱可生技术专家，公众号『一树一溪』作者，专注于研究 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 表查询到加锁情况了。

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

关于 SQLE

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

✨ Github：https://github.com/actiontech/sqle

📚 文档：https://actiontech.github.io/sqle-docs/

💻 官网：https://opensource.actionsky.com/sqle/

👥 微信群：请添加小助手加入 ActionOpenSource

🔗 商业支持：https://www.actionsky.com/sqle