mysql中的锁

环境

此次实验所使用的mysql版本为mysql8：

因为我们可以在performance_schema.data_locks中看到锁的情况。

引擎是innodb。事务隔离级别是RR。

表锁

mysql中的锁可以按照锁的粒度分，表锁就是其中的一种（另一种是行锁）。

虽然锁一整张表在实际操作中是不明智的，但我们还是探究一下。

准备的表：

CREATE TABLE `test`.`test_innodb_lock` (
  `id` int NOT NULL,
  `name` varchar(255) NOT NULL,
  `score` int NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_score` (`score`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

我们有主键索引id以及二级索引score。

然后插入一些数据：

INSERT INTO `test`.`test_innodb_lock`(`id`, `name`, `score`) VALUES (1, 'Jack', 100);
INSERT INTO `test`.`test_innodb_lock`(`id`, `name`, `score`) VALUES (2, 'Rose', 60);
INSERT INTO `test`.`test_innodb_lock`(`id`, `name`, `score`) VALUES (3, 'Ocean', 77);

为了看到performance_schema.data_locks中锁的情况，我们需要设置：

set autocommit=0;

S锁

首先看看表级别的读锁：

读锁可以被多次获取（session1和session2同时获取到了读锁）。

我们可以看到in_use的数量增加了。

然后我们查看锁的情况：

SELECT
  ENGINE,
  OBJECT_SCHEMA,
  OBJECT_NAME,
  INDEX_NAME,
  LOCK_TYPE,
  LOCK_MODE,
  LOCK_STATUS,
  LOCK_DATA
FROM performance_schema.data_locks;

可以看到一个S锁（Share Lock）。

在读锁锁整张表的情况下：

三个session都能够读。

但是：

锁表的session1和session2报错，旁观者session3阻塞。

我们的确可以看到一个阻塞的语句。

session1和session2回滚并解锁表。

X锁

重新做实验。

在session1获取表级别的写锁之后，session2无法再次获取。我们取消session2的获取操作。

现在我们看到了一把X锁（Exclusive Lock）。

持有锁的session1能读能写，其他session则不行。

我们可以看一下mysql官网的总结：

行级锁和意向锁

我们不会主动去锁表，我们常用的是行级别的锁。

行级别的锁有很多。我们看二级索引score，它有几个值：60，79，100，由此可以划分区间。

小于60
60
60至79
79
79至100
大于100

如果我们要添加锁，我们可以锁一行，比如score=60这一行，也可以锁区间，比如60至79这个区间，一切都要看innodb怎么去实现了。

S行锁

全部开启事务。

我们看到了两种锁：IS表示Intention Share Lock，S表示Share Lock，REC_NOT_GAP表示Record Lock but Not a Gap Lock（行锁而非间隙锁）。所以S,REC_NOT_GAP就表示这是一个行锁，是个共享锁，不是一个间隙锁。

IS是一种表锁，如果一个session想去获取一个S锁，就必须先去获取IS锁，即使你最终可能获取S锁失败了，你也要去持有IS锁（表达自己的一个意愿）。

S锁是一种行级的共享锁，作用在主键上（一定要有主键，你没有人家给你生成一个）。

既然id=1的行被session1持有了行锁，我们看看session2能做些什么？

可以查，但是不能修改。

我们可以看到有人试图去获取id=1这一行X锁（写锁），显然这是session2的意图。在waiting地去获取id=1条记录的X锁时，他已经成功地获取了IX锁（Intention Exclusive Lock）。

当session2因为无法获取写锁而超时时：

IX锁还是被session2持有着，这个Intention还是保留着。

session2rollback。

此时IX锁才被释放。

---

和表级S锁一样行级的S锁也可以被多个session获得。

读锁的含义其实就是当前事务进入了读的状态，当然所有事务都可以这么做。但是，如果你想改，不好意思，没有一个事务中能改，不管你持不持有读锁。只有当这一行的读锁全部释放，它才能够被修改。

---

X行锁

同理，我们可以看看行级的X锁。

和料想的一样，一个IX锁，一个X锁。

session2只能拿到IX锁，拿不到X锁。

当然，session2也拿不到读锁。

只有持有写锁的session1才能修改。

所以for update或者说X锁的含义究竟是什么？他就像是在说：我锁定了（session1），接下来要有写操作了，其他人不能进入read mode，也不能进入write mode，其他人就等我完事吧。

---

我们的表里有主键索引id和二级索引score，暂时我们都在使用主键索引，我们可以先看看如果查询语句不使用索引会怎样（使用二级索引score作为查询条件的话情况会更加复杂）。

三条记录都被锁住了。而且是我们没有接触到的一种锁，单纯的S锁（next-key lock），等下我们会介绍这个锁。

当前就认为id=1，id=2，id=3三条记录都添加了行锁就行。

此时session2对id=3的记录也不能更新了。

作为对比，我们看看如果使用主键索引的情况：

只锁id=1一行的话session2是可以更新id=3的数据的。

---

另外，我们常用的其他当前读：update和delete，mysql也是给加了写锁的。

---

Gap锁和Next-key锁

gap锁就是间隙锁，我们上面看到过，我们不仅能对一行加锁，还能对行与行之间的间隙加锁。

next-key锁就是锁两个东西，一个是锁行，另一个是锁行前面的那个间隙，就是这两把锁的合并。

为了更好的演示，我们修改一下数据：

我们为二级索引加写锁：

这里：

• IX是意向锁，要拿到X必须先拿到IX锁。
• X是next-key锁，锁住score=60对应的行和score在50至60之间的数据。
• X,REC_NOT_GAP是行锁，锁住id=21这一行。
• X,GAP是间隙锁，锁住score在60至70间的数据。

边界数据score=50是否锁住需要查看。

我们先看插入的情况：

50（包含）到60，60到76都不能插入，但是score=77可以。这里就可以看出next-key lock和gap lock之间的区别了。

对于update操作，51（包含）到60，60到76都不行，score改成50或者77可以。

从这里也可以看出gap lock和next-key lock作用范围也太大了。

---

如果没有使用索引，则给全表加上next-key lock。

这时候没有任何插入操作能够成功。

当我们使用RR的时候，需要注意gap lock和next-key lock带来的开销。

死锁

死锁就是两个事务（或者多个）互相持有并去索取锁（和java死锁一样）。

session1先去持有id=2这一行的S锁。

session2尝试去获取id=2这行的X锁，由于S和X互斥，session2等待。

在session2等待的过程中，session1去获取id=2这行的X锁。这时候死锁就发生了：

session2已经发出请求X锁的需要，等待session1释放S锁；session1又去请求正被session2“持有”的X锁，互相盯着对方碗里的锁，就会发生死锁。（session1的S锁不能直接升级成X锁，因为它已经被session2请求了）

innodb自己会发现死锁并打破循环。

此时session1同时获取id=2这一行的S锁和X锁。

使用

SHOW ENGINE INNODB STATUS

我们可以看到更多细节：

session2的情况：

session1的情况：