MySQL InnoDB锁先容及差异SQL语句别离加什么样的锁

supremum pseudo-record上的next-key lock锁定了“比索引中当前现实存在的最大值还要大”的谁人世隙，“比大还大”，“bigger than bigger”

6、 插入意向锁(Insert Intention Locks)

一种非凡的gap lock。INSERT操纵插入乐成后，会在新插入的行上配置index record lock，但，在插入行之前，INSERT操纵会起首在索引记录之间的间隙上配置insert intention lock，该锁的范畴是(插入值, 向下的一个索引值)。有shard或exclusive两种模式，但，两种模式没有任何区别，二者等价。

LOCK_MODE别离是：S,GAP,INSERT_INTENTION或X,GAP,INSERT_INTENTION。

insert intention lock发出按此方法举办插入的意图：多个事宜向统一个index gap并发举办插入时，多个事宜无需彼此守候。

假设已存在值为4和7的索引记录，事宜T1和T2各自实行插入索引值5和6，在获得被插入行上的index record lock前，俩事宜都起首配置insert intention lock，于是，T1 insert intention lock (5, 7)，T2 insert intention lock (6, 7)，尽量这两个insert intention lock重叠了，T1和T2并不相互阻塞。

假如gap lock或next-key lock 与 insert intention lock 的范畴重叠了，则gap lock或next-key lock会阻塞insert intention lock。断绝级别为RR时正是操作此特征来办理phantom row题目;尽量insert intention lock也是一种非凡的gap lock，但它和平凡的gap lock差异，insert intention lock彼此不会阻塞，这极大的提供了插入时的并发性。总结如下：

1. gap lock会阻塞insert intention lock。究竟上，gap lock的存在只是为了阻塞insert intention lock
2. gap lock彼此不会阻塞
3. insert intention lock彼此不会阻塞
4. insert intention lock也不会阻塞gap lock

INSERT插入行之前，起首在索引记录之间的间隙上配置insert intention lock，操纵插入乐成后，会在新插入的行上配置index record lock。

我们用下面三图来声名insert intention lock的范畴和特征

上图演示了：T1配置了gap lock(13, 18)，T2配置了insert intention lock(16, 18)，两个锁的范畴重叠了，于是T1 gap lock(13, 18)阻塞了T2 insert intention lock(16, 18)。

上图演示了：T1配置了insert intention lock(13, 18)、index record lock 13;T2配置了gap lock(17, 18)。尽量T1 insert intention lock(13, 18) 和 T2 gap lock(17, 18)重叠了，但，T2并未被阻塞。由于 insert intention lock 并不阻塞 gap lock。

上图演示了：T1配置了insert intention lock(11, 18)、index record lock 11;T2配置了next-key lock(5, 11]、PRIMARY上的index record lock 'b'、gap lock(11, 18)。此时：T1 index record lock 11 和 T2 next-key lock(5, 11]斗嘴了，因此，T2被阻塞。

7、自增锁(AUTO-INC Locks)

表锁。向带有AUTO_INCREMENT列 的表时插入数据行时，事宜必要起首获取到该表的AUTO-INC表级锁，以便可以天生持续的自增值。插入语句开始时哀求该锁，插入语句竣事后开释该锁(留意：是语句竣事后，而不是事宜竣事后)。

你也许会想，一般开拓中，我们全部表都行使AUTO_INCREMENT作主键，以是会很是频仍的行使到该锁。不外，工作也许并不像你想的那样。在先容AUTO-INC表级锁之前，我们先来看下和它亲近相干的SQL语句以及体系变量innodb_autoinc_lock_mode

INSERT-like语句

1. insert
2. insert ... select
3. replace
4. replace ... select
5. load data

外加，simple-inserts, bulk-inserts, mixed-mode-inserts

simple-inserts

待插入记录的条数，提前就可以确定(语句初始被处理赏罚时就可以提前确定)因此所必要的自增值的个数也就可以提前被确定。

包罗：不带嵌入子查询的 单行或多行的insert, replace。不外，insert ... on duplicate key update不是

bulk-inserts

待插入记录的条数，不能提前确定，因此所必要的自增值的个数 也就无法提前确定

包罗：insert ... select, replace ... select, load data

在这种环境下，InnoDB只能每次一行的分派自增值。每当一个数据行被处理赏罚时，InnoDB为该行AUTO_INCREMENT列分派一个自增值

mixed-mode-inserts

也是simple-inserts语句，可是指定了某些(非所有)自增列的值。也就是说，待插入记录的条数提前能知道，但，指定了部门的自增列的值。

INSERT INTO t1 (c1,c2) VALUES (1,'a'), (NULL,'b'), (5,'c'), (NULL,'d');

INSERT ... ON DUPLICATE KEY UPDATE也是mixed-mode，最坏环境下，它就是INSERT紧随着一个UPDATE，此时，为AUTO_INCREMENT列所分派的值在UPDATE阶段也许用到，也也许用不到。

再看一下体系变量innodb_autoinc_lock_mode，它有三个候选值0，1，和2

8.0.3之前，默认值是1，即“持续性的锁定模式(consecutive lock mode)”;8.0.3及之后默认值是2，即“交叉性锁定模式(interleaved lock mode)”

a. 当innodb_autoinc_lock_mode=0时，INSERT-like语句都必要获取到AUTO-INC表级锁;

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!