mysql 的锁以及间隙锁

mysql 为并发事务同时对一条记录进行读写时，提出了两种解决方案：

1）使用 mvcc 的方法，实现多事务的并发读写，但是这种读只是“快照读”，一般读的是历史版本数据，还有一种是“当前读”，一般加锁实现“当前读”，或者 insert、update、delete 也是当前读。

2）使用加锁的方法，锁分为共享锁（读锁），排他锁（写锁）

快照读：就是select

当前读：特殊的读 *** 作，插入/更新/删除 *** 作，属于当前读，处理的都是当前的数据，需要加锁。

mysql 在 RR 级别怎么处理幻读的呢？一般来说，RR 级别通过 mvcc 机制，保证读到低于后面事务的数据。但是 select for update 不会触发 mvcc，它是当前读。如果后面事务插入数据并提交，那么在 RR 级别就会读到插入的数据。所以，mysql 使用 行锁 + gap 锁（简称 next-key 锁）来防止当前读的时候插入。

Gap Lock在InnoDB的唯一作用就是防止其他事务的插入 *** 作，以此防止幻读的发生。

Innodb自动使用间隙锁的条件：

加锁情况与死锁原因分析

为方便大家复现，完整表结构和数据如下：

CREATE TABLE `t3` (

`c1` int(11) NOT NULL AUTO_INCREMENT,

`c2` int(11) DEFAULT NULL,

PRIMARY KEY (`c1`),

UNIQUE KEY `c2` (`c2`)

) ENGINE=InnoDB

insert into t3 values(1,1),(15,15),(20,20)

在 session1 执行 commit 的瞬间，我们会看到 session2、session3 的其中一个报死锁。这个死锁是这样产生的：

1. session1 执行 delete  会在唯一索引 c2 的 c2 = 15 这一记录上加 X lock（也就是在MySQL 内部观测到的：X Lock but not gap）；

2. session2 和 session3 在执行 insert 的时候，由于唯一约束检测发生唯一冲突，会加 S Next-Key Lock，即对 (1,15] 这个区间加锁包括间隙，并且被 seesion1 的 X Lock 阻塞，进入等待；

3. session1 在执行 commit 后，会释放 X Lock，session2 和 session3 都获得 S Next-Key Lock；

4. session2 和 session3 继续执行插入 *** 作，这个时候 INSERT INTENTION LOCK（插入意向锁）出现了，并且由于插入意向锁会被 gap 锁阻塞，所以 session2 和 session3 互相等待，造成死锁。

死锁日志如下：

请点击输入图片描述

INSERT INTENTION LOCK

在之前的死锁分析第四点，如果不分析插入意向锁，也是会造成死锁的，因为插入最终还是要对记录加 X Lock 的，session2 和 session3 还是会互相阻塞互相等待。

但是插入意向锁是客观存在的，我们可以在官方手册中查到，不可忽略：

Prior to inserting the row, a type of gap lock called an insert intention gap lock is set. This lock signals the intent to insert in such a way that multiple transactions inserting into the same index gap need not wait for each other if they are not inserting at the same position within the gap.

插入意向锁其实是一种特殊的 gap lock，但是它不会阻塞其他锁。假设存在值为 4 和 7 的索引记录，尝试插入值 5 和 6 的两个事务在获取插入行上的排它锁之前使用插入意向锁锁定间隙，即在（4，7）上加 gap lock，但是这两个事务不会互相冲突等待。

当插入一条记录时，会去检查当前插入位置的下一条记录上是否存在锁对象，如果下一条记录上存在锁对象，就需要判断该锁对象是否锁住了 gap。如果 gap 被锁住了，则插入意向锁与之冲突，进入等待状态（插入意向锁之间并不互斥）。总结一下这把锁的属性：

1. 它不会阻塞其他任何锁；

2. 它本身仅会被 gap lock 阻塞。

在学习 MySQL 过程中，一般只有在它被阻塞的时候才能观察到，所以这也是它常常被忽略的原因吧...

GAP LOCK

在此例中，另外一个重要的点就是 gap lock，通常情况下我们说到 gap lock 都只会联想到 REPEATABLE-READ 隔离级别利用其解决幻读。但实际上在 READ-COMMITTED 隔离级别，也会存在 gap lock ，只发生在：唯一约束检查到有唯一冲突的时候，会加 S Next-key Lock，即对记录以及与和上一条记录之间的间隙加共享锁。

通过下面这个例子就能验证：

请点击输入图片描述

这里 session1 插入数据遇到唯一冲突，虽然报错，但是对 (15,20] 加的 S Next-Key Lock 并不会马上释放，所以 session2 被阻塞。另外一种情况就是本文开始的例子，当 session2 插入遇到唯一冲突但是因为被 X Lock 阻塞，并不会立刻报错 “Duplicate key”，但是依然要等待获取 S Next-Key Lock 。

有个困惑很久的疑问：出现唯一冲突需要加 S Next-Key Lock 是事实，但是加锁的意义是什么？还是说是通过 S Next-Key Lock 来实现的唯一约束检查，但是这样意味着在插入没有遇到唯一冲突的时候，这个锁会立刻释放，这不符合二阶段锁原则。这点希望能与大家一起讨论得到好的解释。

如果是在 REPEATABLE-READ，除以上所说的唯一约束冲突外，gap lock 的存在是这样的：

普通索引（非唯一索引）的S/X Lock，都带 gap 属性，会锁住记录以及前1条记录到后1条记录的左闭右开区间，比如有[4,6,8]记录，delete 6，则会锁住[4,8）整个区间。

对于 gap lock，相信 DBA 们的心情是一样一样的，所以我的建议是：

1. 在绝大部分的业务场景下，都可以把 MySQL 的隔离界别设置为 READ-COMMITTED；

2. 在业务方便控制字段值唯一的情况下，尽量减少表中唯一索引的数量。

锁冲突矩阵

前面我们说的 GAP LOCK 其实是锁的属性，另外我们知道 InnoDB 常规锁模式有：S 和 X，即共享锁和排他锁。锁模式和锁属性是可以随意组合的，组合之后的冲突矩阵如下，这对我们分析死锁很有帮助：

请点击输入图片描述

MySQL 中有哪些锁？

数据库中锁的设计初衷处理并发问题，作为多用户共享资源，当出现并发访问的时候，数据库需要合理控制资源访问规则。锁就是实现这些访问规则中的重要数据。

锁的分类

根据加锁范围，MySQL 里面的锁可以分成 全局锁 、 表级锁 、 行锁 三类。

全局锁

全局锁，就是对整个数据库实例加锁，MySQL 提供了一个加全局读锁的方法，命令是:

Flush tables with read lock (FTWRL)

当需要整个库只读状态的时候，可以使用这个命令，之后其他线程的：数据更新语句（增删改），数据定义语句（建表，修改表结构）和更新事务的提交语句将会被阻塞。

全局锁的使用场景

全局锁的定型使用场景，做 全库逻辑备份 。也就是把整个库每个表都 Select 出来，然后存成文本。

如何整个库都只读，会有什么问题？ 如果你在主库上备份，那么在备份期间都不能执行更想，业务就基本上停摆。 如果在从库上备份，那么备份期间从库不能执行主库同步过来的 binlog ,会导致从延迟。 既然要全库只读， 为什么不使用set global readonly=true的方式呢?

readonly 方式也可以让全库进入只读状态,但我还是会建议你用FTWRL方式， 主要有两个原因：

一是， 在有些系统中， readonly的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库。因此，修改global变量的方式影响面更大， 我不建议你使用。 二是， 在异常处理机制上有差异。如果执行FTWRL命令之后由于客户端发生异常断开， 那么MySQL会自动释放这个全局锁， 整个库回到可以正常更新的状态。而将整个库设置为readonly之后， 如果客户端发生异常， 则数据库就会一直保持readonly状态， 这样会导致整个库长时间处于不可写状态， 风险较高 表级别锁

MySQL 里面表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lok, MDL）。表锁的语法是 ：

lock tables ... read/write

与 FTWRL 类似,可以使用 unlock tables 主动释放锁，也可以在客户端断开的时候自动释放。需要注意的是，lock tables语法除了会限制别的线程的读写外，也限定了本线程接下来的 *** 作对象。

MDL 表级锁

MDL 不需要显示使用，在访问一个表的时候自动加上， MDL 保证读写的正确性，也就是说在查询数据时，不允许有其他线程对这个表结构做变更。

什么 *** 作会加 MDL 锁？

在MySQL 5.5版本中引入了MDL， 当对一个表做增删改查 *** 作的时候，加 MDL读锁 ；当要对表做结构变更 *** 作的时候，加 MDL写锁 。

读锁之间不互斥，因此可以有多个线程同时对一张表增删改查。 读写之间、写锁之间是互斥的，用来保证变更表结构 *** 作的安全性，如果有两个线程要同时给一个表加字段，其中一个要等另外一个执行完才能执行。 更改表结构要注意哪些？

给一个表加字段， 或者修改字段， 或者加索引， 需要扫描全表的数据。在对大表 *** 作的时候， 你肯定会特别小心， 以免对线上服务造成影响。而实际上， 即使是小表， *** 作不慎也会出问题，导致整个库的线程爆满。

举个例子

我们来看一下下面的 *** 作序列， 假设表t是一个小表。

image

session A先启动， 这时候会对表t加一个 MDL读锁 。由于session B需要的也是 MDL读锁 ， 因此可以正常执行。 session C会被blocked， 是因为session A的MDL读锁还没有释放， 而session C需要MDL写锁， 因此只能被阻塞，读写锁互斥。 如果只有session C自己被阻塞还没什么关系， 但是之后所有要在表t上新申请MDL读锁的请求也会被session C阻塞。前面我们说了，所有对表的增删改查 *** 作都需要先申请MDL读锁， 就都被锁住， 等于这个表现在完全不可读写了。

如果某个表上的查询语句频繁， 而且客户端有重试机制，也就是说超时后会再起一个新session 再请求的话， 这个 库的线程很快就会爆满 。事务中的MDL锁， 在语句执行开始时申请， 但是语句结束后并不会马上释放， 而会等到整个事务提交后再释放。

怎么解决这个 更改表结构问题

比较理想的机制是， 在alter table语句里面设定等待时间， 如果在这个指定的等待时间里面能够拿到MDL写锁最好， 拿不到也不要阻塞后面的业务语句， 先放弃。

ALTER TABLE tbl_name NOWAIT add column ... ALTER TABLE tbl_name WAIT N add column ...

---