InnoDB并发插入，居然使用意向锁？
今天，将要介绍InnoDB另外三种：共享/排他锁，意向锁，插入意向锁。
一，共享/排它锁(Shared and Exclusive Locks)
《InnoDB并发为何这么高？》一文介绍了通用的共享/排它锁，在InnoDB里当然也实现了标准的行级锁(row-level locking)，共享/排它锁：
(1)事务拿到某一行记录的共享S锁，才可以读取这一行；
(2)事务拿到某一行记录的排它X锁，才可以修改或者删除这一行；
其兼容互斥表如下：
S X
S 兼容 互斥
X 互斥 互斥
即：
(1)多个事务可以拿到一把S锁，读读可以并行；
(2)而只有一个事务可以拿到X锁，写写/读写必须互斥；
共享/排它锁的潜在问题是，不能充分的并行，解决思路是数据多版本，具体思路在《InnoDB并发为何这么高？》里介绍过，这里不再深入展开。
二，意向锁(Intention Locks)
InnoDB支持多粒度锁(multiple granularity locking)，它允许行级锁与表级锁共存，实际应用中，InnoDB使用的是意向锁。
意向锁是指，未来的某个时刻，事务可能要加共享/排它锁了，先提前声明一个意向。
意向锁有这样一些特点：
(1)首先，意向锁，是一个表级别的锁(table-level locking)；
(2)意向锁分为：
意向共享锁(intention shared lock, IS)，它预示着，事务有意向对表中的某些行加共享S锁
意向排它锁(intention exclusive lock, IX)，它预示着，事务有意向对表中的某些行加排它X锁
举个例子：
select ... lock in share mode，要设置IS锁；
select ... for update，要设置IX锁；
(3)意向锁协议(intention locking protocol)并不复杂：
事务要获得某些行的S锁，必须先获得表的IS锁
事务要获得某些行的X锁，必须先获得表的IX锁
(4)由于意向锁仅仅表明意向，它其实是比较弱的锁，意向锁之间并不相互互斥，而是可以并行，其兼容互斥表如下：
IS IX
IS 兼容 兼容
IX 兼容 兼容
(5)额，既然意向锁之间都相互兼容，那其意义在哪里呢？它会与共享锁/排它锁互斥，其兼容互斥表如下：
S X
IS 兼容 互斥
IX 互斥 互斥
画外音：排它锁是很强的锁，不与其他类型的锁兼容。这也很好理解，修改和删除某一行的时候，必须获得强锁，禁止这一行上的其他并发，以保障数据的一致性。
三，插入意向锁(Insert Intention Locks)
对已有数据行的修改与删除，必须加强互斥锁X锁，那对于数据的插入，是否还需要加这么强的锁，来实施互斥呢？插入意向锁，孕育而生。
插入意向锁，是间隙锁(Gap Locks)的一种（所以，也是实施在索引上的），它是专门针对insert操作的。
画外音：有点尴尬，间隙锁下一篇文章才会介绍，暂且理解为，它是一种实施在索引上，锁定索引某个区间范围的锁。
它的玩法是：
多个事务，在同一个索引，同一个范围区间插入记录时，如果插入的位置不冲突，不会阻塞彼此。
画外音：官网的说法是
Insert Intention Lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap.
这样，之前挖坑的例子，就能够解答了。
在MySQL，InnoDB，RR下：
t(id unique PK, name);
数据表中有数据：
10, shenjian
20, zhangsan
30, lisi
事务A先执行，在10与20两条记录中插入了一行，还未提交：
insert into t values(11, xxx);
事务B后执行，也在10与20两条记录中插入了一行：
insert into t values(12, ooo);
(1)会使用什么锁？
(2)事务B会不会被阻塞呢？
回答：虽然事务隔离级别是RR，虽然是同一个索引，虽然是同一个区间，但插入的记录并不冲突，故这里：
使用的是插入意向锁
并不会阻塞事务B
思路总结
(1)InnoDB使用共享锁，可以提高读读并发；
(2)为了保证数据强一致，InnoDB使用强互斥锁，保证同一行记录修改与删除的串行性；
(3)InnoDB使用插入意向锁，可以提高插入并发；
结尾
假设不是插入并发，而是读写并发，又会是什么样的结果呢？
MySQL，InnoDB，默认的隔离级别(RR)。
t(id unique PK, name);
数据表中有数据：
10, shenjian
20, zhangsan
30, lisi
事务A先执行，查询了一些记录，还未提交：
select * from t where id>10;
事务B后执行，在10与20两条记录中插入了一行：
insert into t values(11, xxx);
这里：
(1)会使用什么锁？
(2)事务B会不会被阻塞呢？
下回分解。
相关文章：
- 2413赞！某些知识点不存在基础和高深之分，作者花费时间整理知识点也是想更多人能够理解这些知识点，技术文章能够让读者有收获就好，公众号又不是针对一个两个读者，嫌文章水的自己整理几篇不水的发出来，敲键盘谁不会敲！
- 2李向科建议作者可以写上知识来源。 例如，你输出的这些知识，通过哪些书籍或资料，可以有一个系统性的认识。11作者MySQL5.6官方文档。
- 658沈剑TI8，好惨。 6只cn队伍，1只胜者组（后续要面对VP，李逵）。 4败者组。 IG已回家。4作者坚信，偶数年！
- 5×V是否使用insert intention lock.看前一个事务是否产生gap屏障，产生就会用。 Select使用快照读，这样就可以可重复读了。
- 3TYBK事务A在RR等级下，单纯select为快照读，读的版本为事务开始时最近的版本。即使事务A未提交，事务B当前也是没有阻碍的，在B插入后，未提交的话只会对主键加锁，与间隙锁无关。这时A再select的话也是和原来结果一样，但是如果A也插入一条与B相同主键的记录，则在B提交前会被阻塞，B提交后会报错。
- 1周添无锁，不阻塞
- 九云锁和MVCC都是并发控制的手段，是在配合使用吗？意向锁、gap锁等，感觉MVCC无法替代，但有了MVCC，是不是就不需要行锁了呢？作者貌似并不是，今后写更多。
- dz617又想了了下，我刚才刚才写的有问题。事务ab插入相同记录，则事务a会依次拿到s nextkeylock，x insert intention lock，x record lock。这时执行事务b，它也首先也是先申请s nextkeylock，这个锁申请会被事务a上的x recordlock阻塞。这时如果事务a执行完毕，那么事务b插入报主键冲突；如果a回滚释放x锁，那么b就可以拿到s nextlock并继续拿到x recordlock，可以插入数据。 如果加入事务c，因为xrecordlock和snextkeylock冲突，那么会出现b和c都在等待拿到s nextkeylock锁，这时如果a提交，报主键重复；如果a回滚，释放x锁，这时b和c拿到s nextkeylock锁，然后开始申请x insert intention locks锁，因为s锁和x锁冲突，bc都在等待对方释放s锁，产生死锁。 不知道对不对，自己写下来理一下。沈总能看到的话请多指点
- 发表于 2018-09-06 00:07
- 阅读 ( 46 )
