锁：对 “某种范围” 的数据上 “某种锁”

1.“某种范围”：行、表 2.“某种锁”

2.1 共享锁Shared Locks(S锁)

1、兼容性：加了S锁的记录，允许其他事务再加S锁，不允许其他事务再加X锁

2、加锁方式：select…lock in share mode

2.2 排他锁Exclusive Locks(X锁)

1、兼容性：加了X锁的记录，不允许其他事务再加S锁或者X锁

2、加锁方式：select…for update

2.3 表锁：意向锁 Intention Locks，意向锁相互兼容

1、表明“某个事务正在某些行持有了锁、或该事务准备去持有锁”

2、意向锁的存在是为了协调行锁和表锁的关系，支持多粒度(表锁与行锁)的锁并存，。

3、例子：事务A修改user表的记录r，会给记录r上一把行级的排他锁(X)，同时会给user表上一把意向排他锁(IX)，这时事务B要给user表上一个表级的排他锁就会被阻塞。意向锁通过这种方式实现了行锁和表锁共存且满足事务隔离性的要求。

4、1)意向共享锁(IS锁)：事务在请求S锁前，要先获得IS锁

2)意向排他锁(IX锁)：事务在请求X锁前，要先获得IX锁

q1：为什么意向锁是表级锁呢？

当我们需要加一个排他锁时，需要根据意向锁去判断表中有没有数据行被锁定(行锁)；

(1)如果意向锁是行锁，则需要遍历每一行数据去确认；

(2)如果意向锁是表锁，则只需要判断一次即可知道有没数据行被锁定，提升性能。

q2：意向锁怎么支持表锁和行锁并存？

(1)首先明确并存的概念是指数据库同时支持表、行锁，而不是任何情况都支持一个表中同时有一个事务A持有行锁、又有一个事务B持有表锁，因为表一旦被上了一个表级的写锁，肯定不能再上一个行级的锁。

(2)如果事务A对某一行上锁，其他事务就不可能修改这一行。这与“事务B锁住整个表就能修改表中的任意一行”形成了冲突。所以，没有意向锁的时候，让行锁与表锁共存，就会带来很多问题。于是有了意向锁的出现，如q1的答案中，数据库不需要在检查每一行数据是否有锁，而是直接判断一次意向锁是否存在即可，能提升很多性能。

5、下图表示意向锁和共享锁、排他锁的兼容关系。

意思是 当事务A对某个数据范围(行或表)上了“某锁”后，另一个事务B是否能在这个数据范围上“某锁”。

意向锁相互兼容，因为IX、IS只是表明申请更低层次级别元素(比如 page、记录)的X、S操作。

因为上了表级S锁后，不允许其他事务再加X锁，所以表级S锁和X、IX锁不兼容

上了表级X锁后，会修改数据，所以表级X锁和 IS、IX、S、X(即使是行排他锁，因为表级锁定的行肯定包括行级速订的行，所以表级X和IX、行级X)不兼容。

注意：上了行级X锁后，行级X锁不会因为有别的事务上了IX而堵塞，一个mysql是允许多个行级X锁同时存在的，只要他们不是针对相同的数据行。

2.4 行锁：记录锁(Record Locks)

(1)记录锁, 仅仅锁住索引记录的一行，在单条索引记录上加锁。

(2)record lock锁住的永远是索引，而非记录本身，即使该表上没有任何索引，那么innodb会在后台创建一个隐藏的聚集主键索引，那么锁住的就是这个隐藏的聚集主键索引。

所以说当一条sql没有走任何索引时，那么将会在每一条聚合索引后面加X锁，这个类似于表锁，但原理上和表锁应该是完全不同的。

2.5 行锁：间隙锁(Gap Locks)

(1)区间锁, 仅仅锁住一个索引区间(开区间，不包括双端端点)。

(2)在索引记录之间的间隙中加锁，或者是在某一条索引记录之前或者之后加锁，并不包括该索引记录本身。

比如在 1、2、3中，间隙锁的可能值有 (∞, 1)，(1, 2)，(2, ∞)，

(3)间隙锁可用于防止幻读，保证索引间的不会被插入数据

2.6  *行锁：临键锁(Next-Key Locks)

(1)record lock + gap lock, 左开右闭区间。

(2)默认情况下，innodb使用next-key locks来锁定记录。select … for update

(3)但当查询的索引含有唯一属性的时候，Next-Key Lock 会进行优化，将其降级为Record Lock，即仅锁住索引本身，不是范围。

(4)Next-Key Lock在不同的场景中会退化:

2.7 行锁：插入意向锁(Insert Intention Locks)

(1)插入意向锁是一种Gap锁，不是意向锁，在insert操作时产生。

(2)在多事务同时写入不同数据至同一索引间隙的时候，并不需要等待其他事务完成，不会发生锁等待。

(3)假设有一个记录索引包含键值4和7，不同的事务分别插入5和6，每个事务都会产生一个加在4-7之间的插入意向锁，获取在插入行上的排它锁，但是不会被互相锁住，因为数据行并不冲突。

(4)插入意向锁不会阻止任何锁，对于插入的记录会持有一个记录锁。

例如test表存在若干数据的数据，先开始一个事务A，插入一条n=5的数据；(图中步骤1)

此时如果开始一个事务B，执行查询 select * from test where n > 4 for update，事务B会申请Gap锁(4, ∞)，申请成功后，被事务A的x锁阻塞，直到x锁被释放。(图中步骤2)

可以看到图中步骤3的信息，在等待事务释放X锁

2.8 锁的兼容性

2.9 表锁：自增锁(AUTO-INC Locks)

AUTO-INC锁是一种特殊的表级锁，发生涉及AUTO_INCREMENT列的事务性插入操作时产生。

3.锁的选择

1.如果更新条件没有走索引，例如执行”update test set name=“hello” where name=“world”;” ，此时会进行全表扫描，扫表的时候，要阻止其他任何的更新操作，所以上升为表锁。

2.如果更新条件为索引字段，但是并非唯一索引(包括主键索引)，例如执行“update test  set name=“hello” where code=9;” 那么此时更新会使用Next-Key Lock。使用Next-Key Lock的原因：

首先要保证在符合条件的记录上加上排他锁，会锁定当前非唯一索引和对应的主键索引的值；

还要保证锁定的区间不能插入新的数据。

如果更新条件为唯一索引，则使用Record Lock(记录锁)。

帮助知识

1.查看事务、锁的sql

select from information_schema.innodb_locks;

select from information_schema.innodb_lock_waits;

select * from information_schema.innodb_trx;

---------------------

作者：Helloworld先生

来源：CSDN

原文：https://blog.csdn.net/u010841296/article/details/84204701

版权声明：本文为博主原创文章，转载请附上博文链接！

mysql数据库在innodb引擎下会出现表锁定和行锁定并存情况，下面我们来分析一下这种场景下数据库的加锁机制和处理方式。

1、在MyISAM 引擎中只有表锁，

LOCK TABLE my_tabl_name READ;  用读锁锁表，会阻塞其他事务修改表数据。

LOCK TABLE my_table_name WRITe; 用写锁锁表，会阻塞其他事务读和写。

默认情况下读请求会加读锁，写请求写锁，并且是锁定整个表，因此大量读的业务这种引擎效率很高。

2、在Innodb引擎又支持行锁，行锁分为共享锁，一个事务对一行的共享只读锁。排它锁，一个事务对一行的排他读写锁。

3、这两中锁定类型的锁共存的问题

考虑这个例子：

事务A锁住了表中的一行，让这一行只能读，不能写。

之后，事务B申请整个表的写锁。

如果事务B申请成功，那么理论上它就能修改表中的任意一行，这与A持有的行锁是冲突的。

数据库需要避免这种冲突，就是说要让B的申请被阻塞，直到A释放了行锁。

数据库要怎么判断这个冲突呢？

step1：判断表是否已被其他事务用表锁锁表

step2：判断表中的每一行是否已被行锁锁住。

注意step2中通过遍历查询，这样的判断方法效率实在不高，因为需要遍历整个表。

于是就有了意向锁。

在意向锁存在的情况下，事务A必须先申请表的意向共享锁，成功后再申请一行的行锁。

在意向锁存在的情况下，上面的判断可以改成

step1：不变

step2：发现表上有意向共享锁，说明表中有些行被共享行锁锁住了，因此，事务B申请表的写锁会被阻塞。

最终结论：

(1)申请意向锁的动作是数据库完成的，就是说，事务A申请一行的行锁的时候，数据库会自动先开始申请表的意向锁，不需要我们程序员使用代码来申请。

(2)IX，IS是表级锁，不会和行级的X，S锁发生冲突。只会和表级的X，S发生冲突

行级别的X和S按照普通的共享、排他规则即可。所以之前的示例中第2步不会冲突，只要写操作不是同一行，就不会发生冲突。

备注:  IX  意向排它锁，IS 意向读锁，X 排它锁，S 共享锁