【MySQL】锁机制

文章目录

一、表级锁和行级锁
二、排他锁和共享锁
三、InnoDB行级锁
- 行级锁
- 间隙锁
- 意向共享锁和意向排他锁
四、InnoDB表级锁
五、死锁
六、锁的优化建议

一、表级锁和行级锁

表级锁： 对整张表加锁。开销小，加锁快，不会出现死锁；锁粒度大，发生锁冲突的概率高，并发度低。

行级锁： 对某行记录加锁。开销大，加锁慢，会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度高。

二、排他锁和共享锁

排它锁（Exclusive），又称为X 锁，写锁。
共享锁（Shared），又称为S 锁，读锁。

X和S锁之间有以下的关系： SS可以兼容的，XS、SX、XX之间是互斥的

一个事务对数据对象 O 加了 S 锁，可以对 O 进行读取操作但不能进行更新操作。加锁期间其它事务能对O 加 S 锁但不能加 X 锁。
一个事务对数据对象 O 加了 X 锁，就可以对 O 进行读取和更新。加锁期间其它事务不能对 O 加任何锁。
显示加锁：select ... lock in share mode 强制获取共享锁，select ... for update 获取排它锁。

例如：

先创建一张表结构如下：

在这里插入图片描述

这里事务一 for update 获取了该行记录的排它锁，此时其他事务既不能读也不能写。此时如果事务二想要获取排它锁或共享锁时，也获取不到。

在这里插入图片描述

当然，如果此时事务二想要获取其他行的共享锁或者排它锁时是可以实现的。

在这里插入图片描述

这里我们需要注意的是，在InnoDB中行锁是加在索引上的，如果我们的过滤条件中没有索引，那么就默认加的是表锁。

在这里插入图片描述

三、InnoDB行级锁

行级锁

InnoDB存储引擎支持事务处理，表支持行级锁定，并发能力更好。

InnoDB行锁是通过给索引上的索引项加锁来实现的，而不是给表的行记录加锁实现的，这就意味着只有通过索引条件检索数据，InnoDB才使用行级锁，否则InnoDB将使用表锁。

举一个例子，还是上面的 user 表，我们将 name 一列创建上一个普通索引。

在这里插入图片描述

这里我们可以看到，如果给name一列添加索引时，那么InnoDB就会使用行级锁。

由于InnoDB的行锁实现是针对索引字段添加的锁，不是针对行记录加的锁，因此虽然访问的是InnoDB引擎下表的不同行，但是如果使用相同的索引字段作为过滤条件，依然会发生锁冲突，只能串行进行，不能并发进行。

在这里插入图片描述

即使SQL中使用了索引，但是经过MySQL的优化器后，如果认为全表扫描比使用索引效率更高，此时会放弃使用索引，因此也不会使用行锁，而是使用表锁，比如对一些很小的表，MySQL就不会去使用索引。

在串行化隔离级别中解决了脏读、不可重复读和幻读的问题，因为了在串行化中纯粹使用了共享锁和排它锁。

在这里插入图片描述

这说明了SS锁是可以共享的，SX锁是互斥的。

在这里插入图片描述

如果事务1通过主键索引对一行记录加锁，那么事务2如果通过辅助索引也锁定了和事务1一样的行，那么事务2将不能加锁。

在这里插入图片描述

行锁是给索引加的锁，而不是给数据加的锁。

间隙锁

串行化隔离级别是如何解决幻读问题的？

幻读问题

💕 范围查询

在这里插入图片描述

本质上是通过 间隙锁（gap lock） 解决的。

我们先来看现象：

在这里插入图片描述

下面我们来解决一下原因：

在这里插入图片描述

所以，当事务一向间隙中插入数据时，就会阻塞到间隙锁上面。

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB 会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做 “间隙（GAP)”，InnoDB 也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁。举例来说，假如 user 表中只有 101 条记录，其 userid 的值分别是 1,2,…,100,101，下面的 SQL：

select * from user where userid > 100 for update;

是一个范围条件的检索，InnoDB 不仅会对符合条件的 userid 值为 101 的记录加锁，也会对userid 大于 101（但是这些记录并不存在）的"间隙"加锁，防止其它事务在表的末尾增加数据。

InnoDB使用间隙锁的目的，为了防止幻读，以满足串行化隔离级别的要求，对于上面的例子，要是不使用间隙锁，如果其他事务插入了 userid 大于 100 的任何记录，那么本事务如果再次执行上述语句，就会发生幻读。

间隙锁的加锁范围

现象一：

在这里插入图片描述

原因：

在这里插入图片描述

现象二：

在这里插入图片描述

我们可以看到与预期的现象不同，这是什么原因呢？

在这里插入图片描述

其实这是因为事务在查询时，如果发现索引查询和整表查询所得到的行数相差不多时，MySQL就优化查询方式，将索引查询优化为整表查询，这会导致在加锁时直接加的是 表级锁，对整张表加锁会导致插入任何数据都会阻塞。

所以，对于间隙锁的加锁范围，我们应该视情况而定。

💕 等值查询

现象：

在这里插入图片描述

原因：

在这里插入图片描述

因此，串行化隔离在面对等值查询时，也可以通过间隙锁来很好的避免幻读问题。

意向共享锁和意向排他锁

首先我们来看一个问题：如果我们想要获取一张表的表锁时，首先得知道这张表有没有被其他事务获取过锁？因为这张表中可能有其他事务的行级锁！

当我们想要获取一张表的共享锁S或者排它锁X时，最起码得确定，这张表又没有被其他事务获取过X锁！

假如这张表的数据非常大（一千万行数据），那么我们应该如何从中得知它有没有被其他事务获取过行锁X锁呢？

这里我们就可以使用意向锁来解决这里的效率问题了。

意向共享锁（IS锁）：事务计划给记录加行共享锁，事务在给一行记录加共享锁前，必须先取得该表的IS 锁。
意向排他锁（IX锁）：事务计划给记录加行排他锁，事务在给一行记录加排他锁前，必须先取得该表的IX 锁。

在这里插入图片描述

说明一下：

意向锁是由InnoDB存储引擎获取行锁之前自己获取的
意向锁之间都是兼容的，不会产生冲突
意向锁存在的意义是为了更高效的获取表锁（表格中的X和S指的是表锁，不是行锁！！！）
意向锁是表级锁，协调表锁和行锁的共存关系。主要目的是显示事务正在锁定某行或者试图锁定某行

因此，要解决上面所说的效率问题，当我们要获取表的X锁时，不需要再检查表中的哪些行锁（X或者S）占用，只需要快速检查IX和IS锁即可。

四、InnoDB表级锁

在绝大部分情况下都应该使用行锁，因为事务和行锁往往是选择InnoDB的理由，但个别情况下也使用表级锁：

事务需要更新大部分或全部数据，表又比较大，如果使用默认的行锁，不仅这个事务执行效率低，而且可能造成其他事务长时间等待和锁冲突；
事务涉及多个表，比较复杂，很可能引起死锁，造成大量事务回滚。
如：
LOCK TABLE user READ；读锁锁表
LOCK TABLE user WRITE; 写锁锁表
事务执行…
COMMIT/ROLLBACK; 事务提交或者回滚
UNLOCK TABLES; 本身自带提交事务，释放线程占用的所有表锁