mysql的各种锁

在了解mysql中的各种锁之前你还需要了解这些

1、悲观锁乐观锁：https://zhuanlan.zhihu.com/p/31537871

2、mysql索引原理B+ Tree: https://zhuanlan.zhihu.com/p/27700617

3、事务的ACID特性：https://zhuanlan.zhihu.com/p/27789602

4、事务的4种隔离级别：https://zhuanlan.zhihu.com/p/27790194

1、首先了解Innodb 中锁和索引的关系

在innodb中我们的锁都是作用在索引上面的，只有当我们的SQL命中索引时，才会触发行锁，没有命中索引的话我们的锁都是用的表锁(innodb的表锁就是把表的每一行都锁住)。

innodb索引结构图(B+ tree):

 

2、锁的分类

mysql中的锁分为四种（分类方式不属于官方纯属个人理解）：

1、粒度锁： 表锁、行锁；

2、算法锁（基于行锁的算法）：记录锁，间隙锁，临键锁；

3、属性锁：共享锁，排它锁；

4、状态所（基于属性锁的状态）：意向共享锁，意向排它锁；

2-1、粒度锁：表锁、行锁

表锁

表锁是指上锁的时候锁住的是整个表，当下一个事务访问该表的时候，必须等前一个事务释放了锁才能进行对表进行访问；

特点： 粒度大，加锁简单，容易冲突；

 

行锁

行锁是指上锁的时候锁住的是表的某一行或者多行记录，其他事务访问同一张表时，只有被锁住的记录不能访问，其他的记录可正常访问；

特点：粒度小，加锁比表锁麻烦，不容易冲突，相比表锁支持的并发要高；

 

2-2、算法锁：记录锁、间隙锁、临间锁

记录锁(Record Lock)

事务加锁后锁住的只是表的某一条记录。

 

记录锁出现条件：精准条件命中，并且命中的条件字段是唯一索引；

例如：update user_info set name=’张三’ where id=1 ,这里的id是唯一索引。

记录锁的作用：加了记录锁之后可以避免数据在查询的时候被修改的重复读问题，也避免了在修改的事务未提交前被其他事务读取的脏读问题。

 

间隙锁(Gap Lock)

事务加锁后锁住的是表记录的某一个区间，当表的相邻ID之间出现空隙则会形成一个区间，遵循左开右闭原则。

比如下面的表里面的数据ID 为 1,4,5,7,10 ,那么会形成以下几个间隙区间，-n-1区间，1-4区间，7-10区间，10-n区间 （-n代表负无穷大，n代表正无穷大）

 

间隙锁出现的条件：范围查询并且查询未命中记录，查询条件必须命中索引、间隙锁只会出现在REPEATABLE_READ（重复读)的事务级别中。

例如：对应上图的表执行select * from user_info where id>1 and id<4(这里的id是唯一索引) ，这个SQL查询不到对应的记录，那么此时会使用间隙锁。

间隙锁作用？

防止幻读问题，事务并发的时候，如果没有间隙锁，就会发生如下图的问题，在同一个事务里，A事务的两次查询出的结果会不一样。

 

临键锁(Next-Key Lock)

临键锁是INNODB的行锁默认算法，它是记录锁和间隙锁的组合，临键锁会把查询出来的记录锁住，同时也会把该范围查询内的所有间隙空间也会锁住，再之它会把相邻的下一个区间也会锁住。

比如下面表的数据执行 select * from user_info where id>1 and id<=13 for update ;

会锁住ID为 1,5,10的记录；

同时会锁住，1至5,5至10,10至15的区间。

 

出现条件：范围查询并命中，查询命中了索引。

临键锁的作用

结合记录锁和间隙锁的特性，临键锁避免了在范围查询时出现脏读、重复读、幻读问题。加了临键锁之后，在范围区间内数据不允许被修改和插入。

 

2-3、属性锁：共享锁、排他锁

共享锁(Share Lock)

共享锁又称读锁，简称S锁；当一个事务为数据加上读锁之后，其他事务只能对该数据加读锁，而不能对数据加写锁，直到所有的读锁释放之后其他事务才能对其进行加持写锁。

 

共享锁的特性主要是为了支持并发的读取数据，读取数据的时候不支持修改，避免出现重复读的问题。

排他锁（eXclusive Lock）

排他锁又称写锁，简称X锁；当一个事务为数据加上写锁时，其他请求将不能再为数据加任何锁，直到该锁释放之后，其他事务才能对数据进行加锁。

 

排他锁的目的是在数据修改时候，不允许其他人同时修改，也不允许其他人读取。避免了出现脏数据和脏读的问题。

2-4、状态锁：意向共享锁、意向排他锁

 

 

意向锁

当一个事务试图对整个表进行加锁（共享锁或排它锁）之前，首先需要获得对应类型的意向锁（意向共享锁或意向共享锁）。

意向共享锁

当一个事务试图对整个表进行加共享锁之前，首先需要获得这个表的意向共享锁。

意向排他锁

当一个事务试图对整个表进行加排它锁之前，首先需要获得这个表的意向排它锁。

为什么我们需要意向锁？

首先我们先要有一个概念那就是innodb加锁的方式是基于索引，并且加锁粒度是行锁。

然后我们看下面的案例：

第一步：

事务A对user_info表执行一个SQL:update user_info set name =”张三” where id=6 加锁情况如下图;

 

第二步：

与此同时数据库又接收到事务B修改数据的请求：SQL: update user_info set name =”李四”；

1、因为事务B是对整个表进行修改操作，那么此SQL是需要对整个表进行加排它锁的（update加锁类型为排他锁）；

2、我们首先做的第一件事是先检查这个表有没有被别的事务锁住，只要有事务对表里的任何一行数据加了共享锁或排他锁我们就无法对整个表加锁（排他锁不能与任何属性的锁兼容）。

3、因为INNODB锁的机制是基于行锁，那么这个时候我们会对整个索引每个节点一个个检查，我们需要检查每个节点是否被别的事务加了共享锁或排它锁。

4、最后检查到索引ID为6的节点被事务A锁住了，最后导致事务B只能等待事务A锁的释放才能进行加锁操作。

思考：

在A事务的操作过程中，后面的每个需要对user_info加持表锁的事务都需要遍历整个索引树才能知道自己是否能够进行加锁，这种方式是不是太浪费时间和损耗数据库性能了？

所以INNODB就加了意向锁的概念：如果当事务A加锁成功之后就设置一个状态告诉后面的人，已经有人对表里的行加了一个排他锁了，你们不能对整个表加共享锁或排它锁了，那么后面需要对整个表加锁的人只需要获取这个状态就知道自己是不是可以对表加锁，避免了对整个索引树的每个节点扫描是否加锁。