隐式锁
简介
Innodb采用乐观插入的方式，所以在做insert操作时不会进行显示加锁，也就是不会生成lock_t锁结构，这样可以极大的减少锁开销，提升整体的性能。
如果没有显示的行锁，该如何保证事务插入的正确性呢？比如说如下两个事务，插入相同的两个主键数据，如下：
create table test(id int not null auto_increment primary key,name varchar(10));| session1 | session2 |
|---|---|
| begin; | begin; |
| insert into test values(1,’test’); | |
| insert into test values(1,’test’); |
在事务1提交之前，事务2是不会报错主键冲突的，会陷入等待的状态，那么这种阻塞是如何形成的，将会通过这篇文章进行详细介绍。
详解隐式锁
Innodb的行锁结构是基于行数据的，而隐式锁没有真正的行锁结构，它通过每一行数据的隐藏字段来完成。Innodb主键索引的每一行数据包含两个隐藏列，其中一个是trx_id,另外一个是回滚段指针。而主键索引上的隐式锁就是通过trx_id来进行设置的，二级索引上的行数据没有trx_id，但是每一个数据页上包含
一个max_trx_id;
隐式锁加锁流程
在开始研究Insert加锁流程时，一直没看出来是如何操作的，因为在进入加锁代码逻辑中，没有看到设置行数据trx_id的过程。这个过程其实实在之前完成的，在构建Innondb 行数据的时候，就已经把trx_id设置进去了。
- InnoDB的每条记录中都一个隐含的trx_id字段，这个字段存在于簇索引的B+Tree中。
- 假设只有主键索引，则在进行插入时，行数据的trx_id被设置为当前事务id
- 假设存在二级索引，则在对二级索引进行插入时，需要更新所在page的max_trx_id.
判断是否存在隐式锁
对于主键而言，隐式锁的判断只需要查看当前行数据的隐藏列 trx_id是否是活跃事务即可。
对于二级索引会比较麻烦
- 假设R1是二级索引数据，想要检测R1上是否存在其他的事务拥有隐式锁
- 获取R1所在的数据页的最大事务ID T1
- 假设T2是当前事务系统中的最小活跃事务id，如果T1
隐式锁转换
只有在特殊情况下，才会发生隐式锁到显示锁的转换。这个转换动作并不是加隐式锁的线程自发去做的，而是其他存在行数据冲突的线程去做的。
还是看上面的场景：
表结构
create table t1(id int not null auto_increment primary key,name varchar(10))| 操作序号 | session-1 | session-2 |
|---|---|---|
| 1 | begin; | begin; |
| 2 | insert into t1(id,name) values(1,’aaa’); | |
| 3 | insert into t2(id,name) values(1,’aaa’); |
操作2时，s1对行数据（1,’aaa’）加隐式锁，不需要lock_t结构，不需要添加到lock hash table中。show engine innodb status结果如下
------------
TRANSACTIONS
------------
Trx id counter 329052
Purge done for trx's n:o < 329051 undo n:o < 0 state: running but idle
History list length 117
Total number of lock structs in row lock hash table 0 /*lock hash table中没有记录*/
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 281479605203232, not started
0 lock struct(s), heap size 1160, 0 row lock(s)
---TRANSACTION 281479605201056, not started
0 lock struct(s), heap size 1160, 0 row lock(s)
---TRANSACTION 329051, ACTIVE 6 sec
1 lock struct(s), heap size 1160, 0 row lock(s), undo log entries 1
MySQL thread id 3, OS thread handle 123145543389184, query id 87 localhost root操作3时
锁日志如下：
第一，trx_id=329051的事务，也就是第一条插入语句，增加了一个行锁，并且插入到lock hash table中。
2018-09-12T14:45:33.715550+08:00 5 [Note] InnoDB: trx_id: 329051 create a record lock and add it to lock hash table,
space_id: 195
page_no: 3
heap_no: 2
n_bits: 72
primary key: 1
is record lock: 1
is waiting: 0
is gap: 0
is record not gap: 1
is insert intention: 0
lock_mode: 3 (0:LOCK_IS, 1:LOCK_IX, 2:LOCK_S, 3:LOCK_X, 4:LOCK_AUTO_INC, 5:LOCK_NONE)第二，trx=329052的事务，也加了一把锁（heap_no: 2，第一条用户数据；间隙锁，共享）
2018-09-12T14:45:33.723318+08:00 5 [Note] InnoDB: trx_id: 329052 create a record lock and add it to lock hash table,
space_id: 195
page_no: 3
heap_no: 2
n_bits: 72
primary key: 1
is record lock: 1
is waiting: 1
is gap: 0
is record not gap: 0
is insert intention: 0
lock_mode: 2 (0:LOCK_IS, 1:LOCK_IX, 2:LOCK_S, 3:LOCK_X, 4:LOCK_AUTO_INC, 5:LOCK_NONE)第一个锁结构就是由隐式锁转换而来的，而第二把锁处于waiting状态，因为XS冲突导致的。造成如上这种等待的逻辑：
- 事务1 在进行插入操作时，通过游标定位到待插入行数据无数据冲突
- 事务2 在进行插入操作时，通过游标定位到待插入行数据存在主键冲突
- 获取冲突行数据的trx_id
- 检测行数据的trx_id是否为活跃事务id,如果不活跃，则直接返回报错主键冲突
- 如果活跃，则创建显示锁结构，并且加入到lock hash table中
- 随后创建事务2尝试对行记录加锁，但是会遇到锁冲突
- 随后添加对应行锁，并且返回DB_LOCK_WAIT
- 上层检索到DB_LOCK_WAIT则进入等待状态，等待结束或者等待超时后，再进行其他相关处理。
隐式锁转换在5.7中的优化
关于这部分的优化，可以转到https://yq.aliyun.com/articles/41123。
相关博客地址
mysql-5.7对隐式锁转换的优化
https://yq.aliyun.com/articles/41123
Innodb insert操作的大概流程
https://blog.csdn.net/weixin_40581617/article/details/80623276
隐式锁转换的加锁原理图
http://blog.itpub.net/31493717/viewspace-2150833/