MySQL InnoDB锁介绍及不同SQL语句分别加什么样的锁

当我们说到共享锁(S锁)或排它锁(X锁)时，一般是指行上的共享锁或者行上的排它锁。需要注意的是，表锁也存在共享锁和排它锁，即表上的S锁和表上的X锁，表上的锁除了这两种之外，还包括下面将会提到的意向共享锁(Shard Intention Locks)即IS锁、意向排它锁(Exclusive Intention Locks)即IX锁。表上的锁，除了这四种之外，还有其他类型的锁，这些锁都是在访问表的元信息时会用到的(create table/alter table/drop table等)，本文不讨论这些锁，详细可见：常用SQL语句的MDL加锁源码分析。

数据行r上共享锁(S锁)和排它锁(X锁)的兼容性如下：

假设T1持有数据行r上的S锁，则当T2请求r上的锁时：

1. T2请求r上的S锁，则，T2立即获得S锁。T1和T2同时都持有r上的S锁。
2. T2请求r上的X锁，则，T2无法获得X锁。T2必须要等待直到T1释放r上的S锁。

假设T1持有r上的X锁，则当T2请求r上的锁时：

T2请求r上的任何类型的锁时，T2都无法获得锁，此时，T2必须要等待直到T1释放r上的X锁

2、 意向锁(Intention Locks)

表锁。含义是已经持有了表锁，稍候将获取该表上某个/些行的行锁。有shard或exclusive两种模式。

LOCK_MODE分别是：IS或IX。

意向锁用来锁定层级数据结构，获取子层级的锁之前，必须先获取到父层级的锁。可以这么看InnoB的层级结构：InnoDB所有数据是schema的集合，schema是表的集合，表是行的集合。意向锁就是获取子层级(数据行)的锁之前，需要首先获取到父层级(表)的锁。

意向锁的目的是告知其他事务，某事务已经锁定了或即将锁定某个/些数据行。事务在获取行锁之前，首先要获取到意向锁，即：

1. 事务在获取行上的S锁之前，事务必须首先获取 表上的 IS锁或表上的更强的锁。
2. 事务在获取行上的X锁之前，事务必须首先获取 表上的 IX锁。

事务请求锁时，如果所请求的锁 与 已存在的锁兼容，则该事务 可以成功获得 所请求的锁;如果所请求的锁 与 已存在的锁冲突，则该事务 无法获得 所请求的锁。

表级锁(table-level lock)的兼容性矩阵如下：

对于上面的兼容性矩阵，一定注意两点：

1. 在上面的兼容性矩阵中，S是表的(不是行的)共享锁，X是表的(不是行的)排它锁。
2. 意向锁IS和IX 和任何行锁 都兼容(即：和行的X锁或行的S锁都兼容)。

所以，意向锁只会阻塞 全表请求(例如：LOCK TABLES ... WRITE)，不会阻塞其他任何东西。因为LOCK TABLES ... WRITE需要设置X表锁，这会被意向锁IS或IX所阻塞。

InnoDB允许表锁和行锁共存，使用意向锁来支持多粒度锁(multiple granularity locking)。意向锁如何支持多粒度锁呢，我们举例如下

T1: SELECT * FROM t1 WHERE i=1 FOR UPDATE;

T2: LOCK TABLE t1 WRITE;

T1执行时，需要获取i=1的行的X锁，但，T1获取行锁前，T1必须先要获取t1表的IX锁，不存在冲突，于是T1成功获得了t1表的IX锁，然后，又成功获得了i=1的行的X锁;T2执行时，需要获取t1表的X锁，但，T2发现，t1表上已经被设置了IX锁，因此，T2被阻塞(因为表的X锁和表的IX锁不兼容)。

假设不存在意向锁，则：

T1执行时，需要获取i=1的行的X锁(不需要获取t1表的意向锁了);T2执行时，需要获取t1表的X锁，T2能否获取到T1表的X锁呢?T2无法立即知道，T2不得不遍历表t1的每一个数据行以检查，是否某个行上已存在的锁和自己即将设置的t1表的X锁冲突，这种的判断方法效率实在不高，因为需要遍历整个表。

所以，使用意向锁，实现了“表锁是否冲突”的快速判断。意向锁就是协调行锁和表锁之间的关系的，或者也可以说，意向锁是协调表上面的读写锁和行上面的读写锁(也就是不同粒度的锁)之间的关系的。

3、 索引记录锁(Record Locks)

也就是所谓的行锁，锁定的是索引记录。行锁就是索引记录锁，所谓的“锁定某个行”或“在某个行上设置锁”，其实就是在某个索引的特定索引记录(或称索引条目、索引项、索引入口)上设置锁。有shard或exclusive两种模式。

LOCK_MODE分别是：S,REC_NOT_GAP或X,REC_NOT_GAP。

行锁就是索引记录锁，索引记录锁总是锁定索引记录，即使表上并未定义索引。表未定义索引时，InnoDB自动创建隐藏的聚集索引(索引名字是GEN_CLUST_INDEX)，使用该索引执行record lock。

4、 间隙锁(Gap Locks)

索引记录之间的间隙上的锁，锁定尚未存在的记录，即索引记录之间的间隙。有shard或exclusive两种模式，但，两种模式没有任何区别，二者等价。

LOCK_MODE分别是：S,GAP或X,GAP。

gap lock可以共存(co-exist)。事务T1持有某个间隙上的gap lock 并不能阻止 事务T2同时持有 同一个间隙上的gap lock。shared gap lock和exclusive gap lock并没有任何的不同，它俩并不冲突，它俩执行同样的功能。

gap lock锁住的间隙可以是第一个索引记录前面的间隙，或相邻两条索引记录之间的间隙，或最后一个索引记录后面的间隙。

索引是B+树组织的，因此索引是从小到大按序排列的，在索引记录上查找给定记录时，InnoDB会在第一个不满足查询条件的记录上加gap lock，防止新的满足条件的记录插入。

（编辑：厦门网）

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