隐式锁就像是口头协议，这种口头协议怎么落到实处起作用？
作者：操盛春，爱可生技术专家，公众号『一树一溪』作者，专注于研究 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 表查询到加锁情况了。
