【8. MySQL 中的锁】

MySQL 中的锁

​ 按照 MySQL 官方的说法，InnoDB 中锁可以分为：

​ 可见，InnoDB 中锁非常多，总的来说，可以如下分类：

解决并发事务问题

​ 我们已经知道事务并发执行时可能带来的各种问题，最大的一个难点是：一 方面要最大程度地利用数据库的并发访问，另外一方面还要确保每个用户能以一 致的方式读取和修改数据，尤其是一个事务进行读取操作，另一个同时进行改动 操作的情况下。

复习并发事务问题

​ 一个事务进行读取操作，另一个进行改动操作,我们前边说过，这种情况下 可能发生脏读、不可重复读、幻读的问题。

方案一：读操作 MVCC，写操作进行加锁

​ 所谓的 MVCC 我们在前一章有过详细的描述，就是通过生成一个 ReadView， 然后通过 ReadView 找到符合条件的记录版本（历史版本是由 undo 日志构建的）， 其实就像是在生成 ReadView 的那个时刻做了一个快照，查询语句只能读到在生 成 ReadView 之前已提交事务所做的更改，在生成 ReadView 之前未提交的事务或 者之后才开启的事务所做的更改是看不到的。而写操作肯定针对的是最新版本的 记录，读记录的历史版本和改动记录的最新版本本身并不冲突，也就是采用 MVCC 时，读-写操作并不冲突。

​ 我们说过普通的 SELECT 语句在 READ COMMITTED 和 REPEATABLE READ 隔离 级别下会使用到 MVCC 读取记录。在 READ COMMITTED 隔离级别下，一个事务 在执行过程中每次执行 SELECT 操作时都会生成一个 ReadView，ReadView 的存在 本身就保证了事务不可以读取到未提交的事务所做的更改，也就是避免了脏读现 象；REPEATABLE READ 隔离级别下，一个事务在执行过程中只有第一次执行 SELECT 操作才会生成一个 ReadView，之后的 SELECT 操作都复用这个 ReadView， 这样也就避免了不可重复读和很大程度上避免了幻读的问题。

一致性读（Consistent Reads）/快照读

​ 事务利用 MVCC 进行的读取操作称之为一致性读，或者一致性无锁读，也称 之为快照读，但是往往读取的是历史版本数据。所有普通的 SELECT 语句（plain SELECT）在 READ COMMITTED、REPEATABLE READ 隔离级别下都算是一致性读。 上面的这句话中，普通的 SELECT 语句是指不加锁的 select 语句在非串行化事务 隔离级别下。

​ 一致性读并不会对表中的任何记录做加锁操作，其他事务可以自由的对表中 的记录做改动。

​ 很明显，采用 MVCC 方式的话，读-写操作彼此并不冲突，性能更高，采用 加锁方式的话，读-写操作彼此需要排队执行，影响性能。一般情况下我们当然 愿意采用 MVCC 来解决读-写操作并发执行的问题，但是业务在某些情况下，要 求必须采用加锁的方式执行。

方案二：读、写操作都采用加锁的方式

​ 如果我们的一些业务场景不允许读取记录的旧版本，而是每次都必须去读取 记录的最新版本，比方在银行存款的事务中，你需要先把账户的余额读出来，然 后将其加上本次存款的数额，最后再写到数据库中。在将账户余额读取出来后， 就不想让别的事务再访问该余额，直到本次存款事务执行完成，其他事务才可以 访问账户的余额。这样在读取记录的时候也就需要对其进行加锁操作，这样也就 意味着读操作和写操作也像写-写操作那样排队执行。

​ 我们说脏读的产生是因为当前事务读取了另一个未提交事务写的一条记录， 如果另一个事务在写记录的时候就给这条记录加锁，那么当前事务就无法继续读 取该记录了，所以也就不会有脏读问题的产生了。

​ 不可重复读的产生是因为当前事务先读取一条记录，另外一个事务对该记录 做了改动之后并提交之后，当前事务再次读取时会获得不同的值，如果在当前事 务读取记录时就给该记录加锁，那么另一个事务就无法修改该记录，自然也不会 发生不可重复读了。

​ 我们说幻读问题的产生是因为当前事务读取了一个范围的记录，然后另外的 事务向该范围内插入了新记录，当前事务再次读取该范围的记录时发现了新插入 的新记录，我们把新插入的那些记录称之为幻影记录。采用加锁的方式解决幻读 问题就有不太容易了，因为当前事务在第一次读取记录时那些幻影记录并不存在， 所以读取的时候加锁就有点麻烦 —— 因为并不知道给谁加锁。InnoDB 中是如 何解决的，我们后面会讲到。

锁定读（Locking Reads）/LBCC

​ 也称当前读, 读取的是最新版本, 并且对读取的记录加锁, 阻塞其他事务同 时改动相同记录，避免出现安全问题。

​ 哪些是当前读呢？select lock in share mode (共享锁)、select for update (排他 锁)、update (排他锁)、insert (排他锁)、delete (排他锁)、串行化事务隔离级别都 是当前读

​ 当前读这种实现方式，也可以称之为 LBCC（基于锁的并发控制，Lock-Based Concurrency Control），怎么做到？

共享锁和独占锁

​ 在使用加锁的方式解决问题时，由于既要允许读-读情况不受影响，又要使 写-写、读-写或写-读情况中的操作相互阻塞，MySQL 中的锁有好几类：

​ 共享锁，英文名：Shared Locks，简称 S 锁。在事务要读取一条记录时，需 要先获取该记录的 S 锁。

​ 独占锁，也常称排他锁，英文名：Exclusive Locks，简称 X 锁。在事务要改 动一条记录时，需要先获取该记录的 X 锁。

​ S 锁和 S 锁是兼容的，S 锁和 X 锁是不兼容的，X 锁和 X 锁也是 不兼容的，画个表表示一下就是这样：

​ X 不兼容 X 不兼容 S

​ S 不兼容 X 兼容 S

锁定读的 SELECT 语句

​ MySQ 有两种比较特殊的 SELECT 语句格式：

​ 对读取的记录加 S 锁：

​ SELECT … LOCK IN SHARE MODE;

​ 如果别的事务想要获取这些记录的 X 锁，那么它们会阻塞，直到当前事务提 交之后将这些记录上的 S 锁释放掉。

​ 对读取的记录加 X 锁：

​ SELECT … FOR UPDATE;

写操作的锁

​ 平常所用到的写操作无非是 DELETE、UPDATE、INSERT 这三种：

DELETE：

​ 对一条记录做 DELETE 操作的过程其实是先在 B+树中定位到这条记录的位置， 然后获取这条记录的 X 锁，然后再执行 delete mark 操作。我们也可以把这 个定位待删除记录在 B+树中位置的过程看成是一个获取 X 锁的锁定读。

INSERT：

​ 一般情况下，新插入一条记录的操作并不加锁，InnoDB 通过一种称之为隐 式锁来保护这条新插入的记录在本事务提交前不被别的事务访问。当然，在一些 特殊情况下 INSERT 操作也是会获取锁的，具体情况我们后边再说。

UPDATE：

​ 在对一条记录做 UPDATE 操作时分为三种情况：

​ 如果未修改该记录的键值并且被更新的列占用的存储空间在修改前后未发 生变化，则先在 B+树中定位到这条记录的位置，然后再获取下记录的 X 锁， 最后在原记录的位置进行修改操作。其实我们也可以把这个定位待修改记录在 B+树中位置的过程看成是一个获取 X 锁的锁定读。

​ 如果未修改该记录的键值并且至少有一个被更新的列占用的存储空间在修 改前后发生变化，则先在 B+树中定位到这条记录的位置，然后获取一下记录的 X 锁，将该记录彻底删除掉（就是把记录彻底移入垃圾链表），最后再插入一条新 记录。这个定位待修改记录在 B+树中位置的过程看成是一个获取 X 锁的锁定读， 新插入的记录由 INSERT 操作提供的隐式锁进行保护。

​ 如果修改了该记录的键值，则相当于在原记录上做 DELETE 操作之后再来一 次 INSERT 操作，加锁操作就需要按照 DELETE 和 INSERT 的规则进行了。

锁的粒度

​ 我们前边提到的锁都是针对记录的，也可以被称之为行级锁或者行锁，对一 条记录加锁影响的也只是这条记录而已，我们就说这个锁的粒度比较细；其实一 个事务也可以在表级别进行加锁，自然就被称之为表级锁或者表锁，对一个表加锁影响整个表中的记录，我们就说这个锁的粒度比较粗。给表加的锁也可以分为 共享锁（S 锁）和独占锁（X 锁）

表锁与行锁的比较

锁定粒度：表锁 > 行锁

加锁效率：表锁 > 行锁

冲突概率：表锁 > 行锁

并发性能：表锁 < 行锁

给表加 S 锁

如果一个事务给表加了 S 锁，那么：

别的事务可以继续获得该表的 S 锁

别的事务可以继续获得该表中的某些记录的 S 锁

别的事务不可以继续获得该表的 X 锁

别的事务不可以继续获得该表中的某些记录的 X 锁

给表加 X 锁

如果一个事务给表加了 X 锁（意味着该事务要独占这个表），那么：

别的事务不可以继续获得该表的 S 锁

别的事务不可以继续获得该表中的某些记录的 S 锁

别的事务不可以继续获得该表的 X 锁

别的事务不可以继续获得该表中的某些记录的 X 锁。

​ 为了更好的理解这个表级别的 S 锁和 X 锁和后面的意向锁，我们举一个现实 生活中的例子。我们用曾经很火爆的互联网风口项目共享 Office 来说明加锁：

​ 共享 Office 有栋大楼，楼自然有很多层。办公室都是共享的，客户可以随便 选办公室办公。每层楼可以容纳客户同时办公，每当一个客户进去办公，就相当 于在每层的入口处挂了一把 S 锁，如果很多客户进去办公，相当于每层的入口处 挂了很多把 S 锁（类似行级别的 S 锁）

​ 有的时候楼层会进行检修，比方说换地板，换天花板，检查水电啥的，这些 维修项目并不能同时开展。如果楼层针对某个项目进行检修，就不允许客户来办 公，也不允许其他维修项目进行，此时相当于楼层门口会挂一把 X 锁（类似行级 别的 X 锁）。

​ 上边提到的这两种锁都是针对楼层而言的，不过有时候我们会有一些特殊的 需求：

​ A、有投资人要来考察 Office 的环境。

​ 投资人和公司并不想影响客户进去办公，但是此时不能有楼层进行检修，所 以可以在大楼门口放置一把 S 锁（类似表级别的 S 锁）。此时：

​ 来办公的客户们看到大楼门口有 S 锁，可以继续进入大楼办公。

​ 修理工看到大楼门口有 S 锁，则先在大楼门口等着，啥时候投资人走了，把 大楼的 S 锁撤掉再进入大楼维修

​ B、公司要和房东谈条件。

​ 此时不允许大楼中有正在办公的楼层，也不允许对楼层进行维修。所以可以 在大楼门口放置一把 X 锁（类似表级别的 X 锁）。此时：

​ 来办公的客户们看到大楼门口有 X 锁，则需要在大楼门口等着，啥时候条件 谈好，把大楼的 X 锁撤掉再进入大楼办公。

​ 修理工看到大楼门口有 X 锁，则先在大楼门口等着，啥时候结束，把大 楼的 X 锁撤掉再进入大楼维修。

意向锁(方便对整体加锁的方式)

​ 但是在上面的例子这里头有两个问题：

​ 如果我们想对大楼整体上 S 锁，首先需要确保大楼中的没有正在维修的楼层， 如果有正在维修的楼层，需要等到维修结束才可以对大楼整体上 S 锁。

​ 如果我们想对大楼整体上 X 锁，首先需要确保大楼中的没有办公的楼层以及 正在维修的楼层，如果有办公的楼层或者正在维修的楼层，需要等到全部办公的 同学都办公离开，以及维修工维修完楼层离开后才可以对大楼整体上 X 锁。

​ 我们在对大楼整体上锁（表锁）时，怎么知道大楼中有没有楼层已经被上锁 （行锁）了呢？依次检查每一楼层门口有没有上锁？那这效率也太慢了吧！于是 InnoDB 提出了一种意向锁（英文名：Intention Locks）：

​ 意向共享锁，英文名：Intention Shared Lock，简称 IS 锁。当事务准备在某条 记录上加 S 锁时，需要先在表级别加一个 IS 锁。

​ 意向独占锁，英文名：Intention Exclusive Lock，简称 IX 锁。当事务准备在某 条记录上加 X 锁时，需要先在表级别加一个 IX 锁。

​ 视角回到大楼和楼层上来:

​ 如果有客户到楼层中办公，那么他先在整栋大楼门口放一把 IS 锁（表级锁）， 然后再到楼层门口放一把 S 锁（行锁）。

​ 如果有维修工到楼层中维修，那么它先在整栋大楼门口放一把 IX 锁（表级 锁），然后再到楼层门口放一把 X 锁（行锁）。

​ 之后：

​ 如果有投资人要参观大楼，也就是想在大楼门口前放 S 锁（表锁）时，首先 要看一下大楼门口有没有 IX 锁，如果有，意味着有楼层在维修，需要等到维修 结束把 IX 锁撤掉后才可以在整栋大楼上加 S 锁。

​ 如果有谈条件要占用大楼，也就是想在大楼门口前放 X 锁（表锁）时，首先 要看一下大楼门口有没有 IS 锁或 IX 锁，如果有，意味着有楼层在办公或者维修， 需要等到客户们办完公以及维修结束把 IS 锁和 IX 锁撤掉后才可以在整栋大楼上 加 X 锁。

​ 注意： 客户在大楼门口加 IS 锁时，是不关心大楼门口是否有 IX 锁的，维修 工在大楼门口加 IX 锁时，是不关心大楼门口是否有 IS 锁或者其他 IX 锁的。IS 和IX 锁只是为了判断当前时间大楼里有没有被占用的楼层用的，也就是在对大楼加 S 锁或者 X 锁时才会用到。

​ 总结一下：IS、IX 锁是表级锁，它们的提出仅仅为了在之后加表级别的 S 锁 和 X 锁时可以快速判断表中的记录是否被上锁，以避免用遍历的方式来查看表中 有没有上锁的记录。就是说其实 IS 锁和 IX 锁是兼容的，IX 锁和 IX 锁是兼容的。 我们画个表来看一下表级别的各种锁的兼容性：

锁的组合性：

​ 行锁才有意向锁, 意向锁不冲突(目的都是为了加行锁)

MySQL 中的行锁和表锁

​ MySQL 支持多种存储引擎，不同存储引擎对锁的支持也是不一样的。当然， 我们重点还是讨论 InnoDB 存储引擎中的锁，其他的存储引擎只是稍微看看。

其他存储引擎中的锁

​ 对于 MyISAM、MEMORY、MERGE 这些存储引擎来说，它们只支持表级锁(所以也不存在意向锁)， 而且这些引擎并不支持事务，所以使用这些存储引擎的锁一般都是针对当前会话 来说的。比方说在 Session 1 中对一个表执行 SELECT 操作，就相当于为这个表加 了一个表级别的 S 锁(并发效率好低)，如果在 SELECT 操作未完成时，Session 2 中对这个表执行 UPDATE 操作，相当于要获取表的 X 锁，此操作会被阻塞，直到 Session 1 中的 SELECT 操作完成，释放掉表级别的 S 锁后，Session 2 中对这个表执行 UPDATE 操 作才能继续获取 X 锁，然后执行具体的更新语句。

​ 因为使用 MyISAM、MEMORY、MERGE 这些存储引擎的表在同一时刻只允许 一个会话对表进行写操作，所以这些存储引擎实际上最好用在只读，或者大部分 都是读操作，或者单用户的情景下。 另外，在 MyISAM 存储引擎中有一个称之 为 Concurrent Inserts 的特性，支持在对 MyISAM 表读取时同时插入记录，这样可 以提升一些插入速度。关于更多 Concurrent Inserts 的细节，详情可以参考文档。

InnoDB 存储引擎中的锁

​ InnoDB 存储引擎既支持表锁，也支持行锁。表锁实现简单，占用资源较少， 不过粒度很粗，有时候你仅仅需要锁住几条记录，但使用表锁的话相当于为表中的所有记录都加锁，所以性能比较差。行锁粒度更细，可以实现更精准的并发控 制。下边我们详细看一下。

InnoDB 中的表级锁

表级别的 S 锁、X 锁

​ 在对某个表执行 SELECT、INSERT、DELETE、UPDATE 语句时，InnoDB 存储引 擎是不会为这个表添加表级别的 S 锁或者 X 锁的。

​ 另外，在对某个表执行一些诸如 ALTER TABLE、DROP TABLE 这类的 DDL 语句 时，其他事务对这个表并发执行诸如 SELECT、INSERT、DELETE、UPDATE 的语句 会发生阻塞，同理，某个事务中对某个表执行 SELECT、INSERT、DELETE、UPDATE 语句时，在其他会话中对这个表执行 DDL 语句也会发生阻塞。这个过程其实是 通过在 server 层使用一种称之为元数据锁（英文名：Metadata Locks，简称 MDL） 来实现的，一般情况下也不会使用 InnoDB 存储引擎自己提供的表级别的 S 锁和 X 锁。

​ 其实这个 InnoDB 存储引擎提供的表级 S 锁或者 X 锁是相当鸡肋，只会在一 些特殊情况下，比方说崩溃恢复过程中用到。不过我们还是可以手动获取一下的， 比方说在系统变量 autocommit=0，innodb_table_locks = 1 时，手动获取 InnoDB 存储引擎提供的表 t 的 S 锁或者 X 锁可以这么写：

​ LOCK TABLES t READ：InnoDB 存储引擎会对表 t 加表级别的 S 锁。

​ LOCK TABLES t WRITE：InnoDB 存储引擎会对表 t 加表级别的 X 锁。

​ 不过请尽量避免在使用 InnoDB 存储引擎的表上使用 LOCK TABLES 这样的手 动锁表语句，它们并不会提供什么额外的保护，只是会降低并发能力而已。

表级别的 IS 锁、IX 锁

​ 当我们在对使用 InnoDB 存储引擎的表的某些记录加 S 锁之前，那就需要先 在表级别加一个 IS 锁，当我们在对使用 InnoDB 存储引擎的表的某些记录加 X 锁 之前，那就需要先在表级别加一个 IX 锁。

​ IS 锁和 IX 锁的使命只是为了后续在加表级别的 S 锁和 X 锁时判断表中是否 有已经被加锁的记录，以避免用遍历的方式来查看表中有没有上锁的记录。我们 并不能手动添加意向锁，只能由 InnoDB 存储引擎自行添加。

表级别的 AUTO-INC 锁

​ 在使用 MySQL 过程中，我们可以为表的某个列添加 AUTO_INCREMENT 属性， 之后在插入记录时，可以不指定该列的值，系统会自动为它赋上递增的值系统实 现这种自动给 AUTO_INCREMENT 修饰的列递增赋值的原理主要是两个：

​ 1、采用 AUTO-INC 锁，也就是在执行插入语句时就在表级别加一个 AUTO-INC 锁，然后为每条待插入记录的 AUTO_INCREMENT 修饰的列分配递增的值，在该 语句执行结束后，再把 AUTO-INC 锁释放掉。这样一个事务在持有 AUTO-INC 锁 的过程中，其他事务的插入语句都要被阻塞，可以保证一个语句中分配的递增值 是连续的。

​ 如果我们的插入语句在执行前不可以确定具体要插入多少条记录（无法预计 即将插入记录的数量），比方说使用 INSERT … SELECT、REPLACE … SELECT 或者LOAD DATA 这种插入语句，一般是使用 AUTO-INC 锁为 AUTO_INCREMENT 修饰的 列生成对应的值。

​ 2、采用一个轻量级的锁，在为插入语句生成 AUTO_INCREMENT 修饰的列的 值时获取一下这个轻量级锁，然后生成本次插入语句需要用到的 AUTO_INCREMENT 列的值之后，就把该轻量级锁释放掉，并不需要等到整个插入 语句执行完才释放锁。

​ 如果我们的插入语句在执行前就可以确定具体要插入多少条记录，比方说我 们上边举的关于表 t 的例子中，在语句执行前就可以确定要插入 2 条记录，那么 一般采用轻量级锁的方式对 AUTO_INCREMENT 修饰的列进行赋值。这种方式可 以避免锁定表，可以提升插入性能。

​ InnoDB 提供了一个称之为 innodb_autoinc_lock_mode 的系统变量来控制到 底使用上述两种方式中的哪种来为 AUTO_INCREMENT 修饰的列进行赋值，当

innodb_autoinc_lock_mode 值为 0 时，一律采用 AUTO-INC 锁；当

innodb_autoinc_lock_mode 值为 2 时，一律采用轻量级锁；当

innodb_autoinc_lock_mode 值为 1 时，两种方式混着来（也就是在插入记录数量 确定时采用轻量级锁，不确定时使用 AUTO-INC 锁）。

​ 不过当 innodb_autoinc_lock_mode 值为 2 时，可能会造成不同事务中的插入 语句为 AUTO_INCREMENT 修饰的列生成的值是交叉的，在有主从复制的场景中 是不安全的。

​ MySQL5.7.X 中缺省为 1。但是mysql8中默认值是2

mysql> show variables like '%autoinc%'
    -> ;
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_autoinc_lock_mode | 2     |
+--------------------------+-------+
1 row in set (0.02 sec)

InnoDB 中的行级锁

​ 行锁，也称为记录锁，顾名思义就是在记录上加的锁。但是要注意，这个记 录指的是通过给索引上的索引项加锁。InnoDB 这种行锁实现特点意味着：只有 通过索引条件检索数据，InnoDB 才使用行级锁，否则，InnoDB 将使用表锁。

​ 不论是使用主键索引、唯一索引或普通索引，InnoDB 都会使用行锁来对数 据加锁。

​ 只有执行计划真正使用了索引，才能使用行锁：即便在条件中使用了索引字 段，但是否使用索引来检索数据是由 MySQL 通过判断不同执行计划的代价来决 定的，如果 MySQL 认为全表扫描效率更高，比如对一些很小的表，它就不会使 用索引，这种情况下 InnoDB 将使用表锁，而不是行锁。

​ 同时当我们用范围条件而不是相等条件检索数据，并请求锁时，InnoDB 会 给符合条件的已有数据记录的索引项加锁。

​ 不过即使是行锁，InnoDB 里也是分成了各种类型的。换句话说即使对同一 条记录加行锁，如果类型不同，起到的功效也是不同的。我们使用前面的 teacher， 增加一个索引，并插入几条记录。

​ INDEX idx_name(name)

​ 我们来看看都有哪些常用的行锁类型。

Record Locks

​ 也叫记录锁，就是仅仅把一条记录锁上，官方的类型名称为：

​ LOCK_REC_NOT_GAP。比方说我们把 number 值为 9 的那条记录加一个记录锁的 示意图如下：

​ 记录锁是有 S 锁和 X 锁之分的，当一个事务获取了一条记录的 S 型记录锁后， 其他事务也可以继续获取该记录的 S 型记录锁，但不可以继续获取 X 型记录锁； 当一个事务获取了一条记录的 X 型记录锁后，其他事务既不可以继续获取该记录 的 S 型记录锁，也不可以继续获取 X 型记录锁；

Gap Locks(对于mvcc的基本解决幻读, 间隙锁是彻底解决幻读)

​ 我们说 MySQL 在 REPEATABLE READ 隔离级别下是可以解决幻读问题的，解 决方案有两种，可以使用 MVCC 方案解决，也可以采用加锁方案解决。但是在使 用加锁方案解决时有问题，就是事务在第一次执行读取操作时，那些幻影记录尚 不存在，我们无法给这些幻影记录加上记录锁。InnoDB 提出了一种称之为 Gap Locks 的锁，官方的类型名称为：LOCK_GAP，我们也可以简称为 gap 锁。

​ 间隙锁实质上是对索引前后的间隙上锁，不对索引本身上锁。

​ 会话 1 开启一个事务，执行

Database changed
mysql> select * from teacher;
+--------+-------+--------------+
| number | name  | domain       |
+--------+-------+--------------+
|      1 | DaFei | 并发编程      |
|      3 | Jack  | 源码系列      |
|      9 | James | Redis        |
|     15 | King  | JVM          |
|     21 | Mark  | MySQL        |
+--------+-------+--------------+

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> update teacher set domain ='Spring' where name='James'; # 使用了name索引才会这样加锁
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

***会对([‘Jack’,3],[‘James’,9])之间, ([‘James’,9], [‘King’,15])之间进行上锁。***(注意不包含 James,9 这条数据也加了锁)

​ 如图中为[‘James’, 9]的记录加了 gap 锁，意味着不允许别的事务在这条记录 前后间隙插入新记录。

Database changed
mysql> begin; insert into teacher value(22,'Jahes','docker'); # 按照索引的插入位置jack(3) jahes(22) James(9)
Query OK, 0 rows affected (0.00 sec)

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

​ 为什么不能插入？因为记录（22,‘Jahes’）要 插入的话，在索引 idx_name 上， 刚好落在([‘James’,9], [‘King’,15])之间，是有锁的，当然不允许插入。

​ 但是当 SQL 语句变为：insert into teacher value(70,‘Kings’,‘docker’);能插入吗？

​ 当然能，因为（70,‘Kings’）这条记录不在被锁的区间内

mysql> insert into teacher value(70,'Kings','docker');
Query OK, 1 row affected (0.00 sec)

Next-Key Locks(记录锁+gap 锁, 可以防止幻读)

​ 有时候我们既想锁住某条记录，又想阻止其他事务在该记录前边的间隙插入 新记录，所以 InnoDB 就提出了一种称之为 Next-Key Locks 的锁，官方的类型名 称为：LOCK_ORDINARY，我们也可以简称为 next-key 锁。next-key 锁的本质就是 一个记录锁和一个 gap 锁的合体。

​ 默认情况下，InnoDB 以 REPEATABLE READ 隔离级别运行。在这种情况下， InnoDB 使用 Next-Key Locks 锁进行搜索和索引扫描，这可以防止幻读的发生。

Insert Intention Locks

​ 我们说一个事务在插入一条记录时需要判断一下插入位置是不是被别的事 务加了所谓的 gap 锁（next-key 锁也包含 gap 锁，后边就不强调了），如果有的 话，插入操作需要等待，直到拥有 gap 锁的那个事务提交。

​ 但是 InnoDB 规定事务在等待的时候也需要在内存中生成一个锁结构，表明 有事务想在某个间隙中插入新记录，但是现在处于等待状态。这种类型的锁命名 为 Insert Intention Locks，官方的类型名称为：LOCK_INSERT_INTENTION，我们也 可以称为插入意向锁。

​ 可以理解为插入意向锁是一种锁的的等待队列，让等锁的事务在内存中进行 排队等待，当持有锁的事务完成后，处于等待状态的事务就可以获得锁继续事务 了。

隐式锁

​ 锁的的维护是需要成本的，为了节约资源，MySQL 在设计提出了了一个隐 式锁的概念。一般情况下 INSERT 操作是不加锁的，当然真的有并发冲突的情况 下下，还是会导致问题的。

​ 所以 MySQL 中，一个事务对新插入的记录可以不显式的加锁，但是别的 事务在对这条记录加 S 锁或者 X 锁时，会去检查索引记录中的 trx_id 隐藏列，然 后进行各种判断，会先帮助当前事务生成一个锁结构，然后自己再生成一个锁结 构后进入等待状态。但是由于事务 id 的存在，相当于加了一个隐式锁。

​ 这样的话，隐式锁就起到了延迟生成锁的用处。这个过程，我们无法干预， 是由引擎自动处理的，对我们是完全透明的

锁的内存结构

​ 所谓的锁其实是一个内存中的结构，在事务执行前本来是没有锁的，也就是 说一开始是没有锁结构和记录进行关联的，当一个事务想对这条记录做改动时， 首先会看看内存中有没有与这条记录关联的锁结构，当没有的时候就会在内存中 生成一个锁结构与之关联。比方说事务 E1 要对记录做改动，就需要生成一个锁 结构与之关联。锁结构里至少要有两个比较重要的属性：

​ trx 信息：代表这个锁结构是哪个事务生成的。

​ is_waiting：代表当前事务是否在等待。

​ 当事务 T1 改动了条记录后，就生成了一个锁结构与该记录关联，因为之前 没有别的事务为这条记录加锁，所以 is_waiting 属性就是 false，我们把这个场景 就称之为获取锁成功，或者加锁成功，然后就可以继续执行操作了。

​ 在事务 T1 提交之前，另一个事务 T2 也想对该记录做改动，那么先去看看有 没有锁结构与这条记录关联，发现有一个锁结构与之关联后，然后也生成了一个 锁结构与这条记录关联，不过锁结构的 is_waiting 属性值为 true，表示当前事务 需要等待，我们把这个场景就称之为获取锁失败，或者加锁失败，或者没有成功 的获取到锁:

​ 在事务 T1 提交之后，就会把该事务生成的锁结构释放掉，然后看看还有没 有别的事务在等待获取锁，发现了事务 T2 还在等待获取锁，所以把事务 T2 对应 的锁结构的 is_waiting 属性设置为 false，然后把该事务对应的线程唤醒，让它继 续执行，此时事务 T2 就算获取到锁了。

​ 这种实现方式非常像并发编程里的 CLH 队列。

​ 对一条记录加锁的本质就是在内存中创建一个锁结构与之关联。那么，一个 事务对多条记录加锁时，是不是就要创建多个锁结构呢。

​ 比如 SELECT * FROM teacher LOCK IN SHARE MODE;

​ 很显然，这条语句需要为 teacher 表中的所有记录进行加锁。那么，是不是 需要为每条记录都生成一个锁结构呢?其实理论上创建多个锁结构没有问题，反而更容易理解。但是如果一个事务要获取 10,000 条记录的锁，要生成 10,000 个 这样的结构，不管是执行效率还是空间效率来说都是很不划算的，所以实际上， 并不是一个记录一个锁结构。

​ 当然锁结构实际是很复杂的，我们大概了解下里面包含哪些元素。

​ 锁所在的事务信息：无论是表级锁还是行级锁，一个锁属于一个事务，这里 记载着该锁对应的事务信息。

​ 索引信息：对于行级锁来说，需要记录一下加锁的记录属于哪个索引。

​ 表锁/行锁信息:表级锁结构和行级锁结构在这个位置的内容是不同的。

​ 具体表现为表级锁记载着这是对哪个表加的锁，还有其他的一些信息；

​ 而行级锁记载了记录所在的表空间、记录所在的页号、区分到底是为哪一条 记录加了锁的数据结构。

​ 锁模式：锁是 IS，IX，S，X 中的哪一种。

​ 锁类型：表锁还是行锁，行锁的具体类型。

​ 其他一些和锁管理相关的数据结构，比如哈希表和链表等。

​ 基本上来说，同一个事务里，同一个数据页面，同一个加锁类型的锁会保存 在一起。

查看事务加锁的情况

show engine innodb status\G

​ 查看事务加锁的情况，不过一般情况下，看不到哪个事务对哪些记录加了那 些锁，需要修改系统变量 innodb_status_output_locks（MySQL5.6.16 引入），缺 省是 OFF。

mysql> show variables like 'innodb_status_output_locks';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| innodb_status_output_locks | OFF   |
+----------------------------+-------+
1 row in set (0.01 sec)

# 我们需要设置为 ON，
mysql> set global innodb_status_output_locks = ON;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'innodb_status_output_locks';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| innodb_status_output_locks | ON    |
+----------------------------+-------+
1 row in set (0.00 sec)

## 然后开启事务，并执行语句 
Database changed
mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from teacher where name > 'King' and name < 'Mark' and domain != 'MySQL' order by name desc for update;
+--------+-------+--------+
| number | name  | domain |
+--------+-------+--------+
|     70 | Kings | docker |
+--------+-------+--------+
1 row in set (0.09 sec)

mysql> show engine innodb status\G
------------
TRANSACTIONS
------------
Trx id counter 2142
Purge done for trx's n:o < 2137 undo n:o < 0 state: running but idle
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 421717151055816, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421717151053392, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421717151052584, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421717151050968, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421717151050160, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 421717151049352, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 2141, ACTIVE 39 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1128, 2 row lock(s)
MySQL thread id 31, OS thread handle 140242158573312, query id 434 localhost root executing
select * from teacher where name > 'King' and name < 'Mark' and domain != 'MySQL' order by name desc for update
------- TRX HAS BEEN WAITING 39 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 5 n bits 80 index idx_name of table `len`.`teacher` trx id 2141 lock_mode X waiting
Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 5; hex 4b696e6773; asc Kings;;
 1: len 4; hex 80000046; asc    F;;

------------------
TABLE LOCK table `len`.`teacher` trx id 2141 lock mode IX 
RECORD LOCKS space id 11 page no 5 n bits 80 index idx_name of table `len`.`teacher` trx id 2141 lock_mode X locks gap before rec
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 4d61726b; asc Mark;;
 1: len 4; hex 80000003; asc     ;;

RECORD LOCKS space id 11 page no 5 n bits 80 index idx_name of table `len`.`teacher` trx id 2141 lock_mode X waiting
Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 5; hex 4b696e6773; asc Kings;;
 1: len 4; hex 80000046; asc    F;;

---TRANSACTION 2140, ACTIVE 120 sec
4 lock struct(s), heap size 1128, 4 row lock(s)
MySQL thread id 30, OS thread handle 140241693579008, query id 415 localhost root
TABLE LOCK table `len`.`teacher` trx id 2140 lock mode IX
RECORD LOCKS space id 11 page no 5 n bits 80 index idx_name of table `len`.`teacher` trx id 2140 lock_mode X locks gap before rec
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 4d61726b; asc Mark;;
 1: len 4; hex 80000003; asc     ;;

RECORD LOCKS space id 11 page no 5 n bits 80 index idx_name of table `len`.`teacher` trx id 2140 lock_mode X
Record lock, heap no 5 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 4b696e67; asc King;;
 1: len 4; hex 8000000f; asc     ;;

Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 5; hex 4b696e6773; asc Kings;;
 1: len 4; hex 80000046; asc    F;;

RECORD LOCKS space id 11 page no 4 n bits 80 index PRIMARY of table `len`.`teacher` trx id 2140 lock_mode X locks rec but not gap
Record lock, heap no 8 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000046; asc    F;;
 1: len 6; hex 000000000840; asc      @;;
 2: len 7; hex 820000008c0110; asc        ;;
 3: len 5; hex 4b696e6773; asc Kings;;
 4: len 6; hex 646f636b6572; asc docker;;

---TRANSACTION 2138, ACTIVE 1772 sec
4 lock struct(s), heap size 1128, 3 row lock(s)
MySQL thread id 26, OS thread handle 140241691940608, query id 375 localhost root
TABLE LOCK table `len`.`teacher` trx id 2138 lock mode IX
RECORD LOCKS space id 11 page no 5 n bits 80 index idx_name of table `len`.`teacher` trx id 2138 lock_mode X
Record lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 5; hex 4a616d6573; asc James;;
 1: len 4; hex 80000009; asc     ;;

RECORD LOCKS space id 11 page no 4 n bits 80 index PRIMARY of table `len`.`teacher` trx id 2138 lock_mode X locks rec but not gap
Record lock, heap no 7 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000009; asc     ;;
 1: len 6; hex 00000000083f; asc      ?;;
 2: len 7; hex 010000011a0793; asc        ;;
 3: len 5; hex 4a616d6573; asc James;;
 4: len 6; hex 537072696e67; asc Spring;;

RECORD LOCKS space id 11 page no 5 n bits 80 index idx_name of table `len`.`teacher` trx id 2138 lock_mode X locks gap before rec
Record lock, heap no 5 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 4b696e67; asc King;;
 1: len 4; hex 8000000f; asc     ;;

• TABLE LOCK table `len`.`teacher` trx id 2141 lock mode IX

​ 表示事务 ID 为 12851 对 len下的 teacher 表加了表级意向独占锁。

• RECORD LOCKS space id 11 page no 5 n bits 80 index idx_name of table \len\.`teacher` trx id 2138 lock_mode X locks gap before rec

  表示一个内存中的锁结构，

​ space id 11：表空间 id 为 11；

​ page no 5：页编号为 5；

​ index PRIMARY：对应的索引是 idx_name；

​ lock_mode X locks gap before rec：存放的是一个 X 型的 gap 锁

Record lock, heap no 5 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 4; hex 4b696e67; asc King;;
1: len 4; hex 8000000f; asc ;; ## 表示的加锁记录的详细信息

• RECORD LOCKS space id 11 page no 5 n bits 80 index idx_name of table `len`.`teacher` trx id 2138 lock_mode X

  表示一个内存中的锁结构，

  space id 11：表空间 id 为 11；

  page no 5：页编号为 5；

  index PRIMARY：对应的索引是 idx_name；

  lock_mode X：存放的是一个 X 型的 next-key 锁

• RECORD LOCKS space id 11 page no 4 n bits 80 index PRIMARY of table len.teacher trx id 2138 lock_mode X locks rec but not gap

  如果是记录锁，则会显示“lock_mode X locks rec but not gap"

死锁和空间锁

​ 一般来说，只要有并发和加锁这两种情况的共同加持下，都会有死锁的身影。 死锁的具体成因，借用我们在并发编程中的内容：

死锁

概念

略

学术化的定义

​ 死锁的发生必须具备以下四个必要条件。

​ 1）互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内 某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待， 直至占有资源的进程用毕释放。(独占)

​ 2）请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源 请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其 它资源保持不放。(对已经拥有的不放手)

​ 3）不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。(我不给)谁也别想要)

​ 4）环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链， 即进程集合{P0，P1，P2，···，Pn}中的 P0 正在等待一个 P1 占用的资源；P1 正在等待 P2 占用的资源，……，Pn 正在等待已被 P0 占用的资源。(相互等待)

​ 理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避 免、预防和解除死锁。

​ 只要打破四个必要条件之一就能有效预防死锁的发生。

​ 只要打破四个必要条件之一就能有效预防死锁的发生。

​ 打破互斥条件：改造独占性资源为虚拟资源，大部分资源已无法改造。

​ 打破不可抢占条件：当一进程占有一独占性资源后又申请一独占性资源而无 法满足，则退出原占有的资源。

​ 打破占有且申请条件：采用资源预先分配策略，即进程运行前申请全部资源， 满足则运行，不然就等待，这样就不会占有且申请。

​ 打破循环等待条件：实现资源有序分配策略，对所有设备实现分类编号，所有进程只能采用按序号递增的形式申请资源。

​ 避免死锁常见的算法有有序资源分配法、银行家算法。

MySQL 中的死锁

会话 1：

begin;

select * from teacher where number = 1 for update;

会话 2：

begin;

select * from teacher where number = 3 for update;

会话 1：

select * from teacher where number = 3 for update;

可以看到这个语句的执行将会被阻塞

会话 2：

select * from teacher where number = 1 for update;

mysql> select * from teacher where number = 1 for update;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

MySQL 检测到了死锁，并结束了会话 2 中事务的执行，此时，切回会话 1， 发现原本阻塞的 SQL 语句执行完成了。

​ 同时通过,可以看见死锁的详细情况：

------------
TRANSACTIONS
------------
Trx id counter 2144
Purge done for trx's n:o < 2137 undo n:o < 0 state: running but idle
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
...
---TRANSACTION 2142, ACTIVE 86 sec
3 lock struct(s), heap size 1128, 2 row lock(s)
MySQL thread id 32, OS thread handle 140242158278400, query id 456 localhost root
TABLE LOCK table `len`.`teacher` trx id 2142 lock mode IX
RECORD LOCKS space id 11 page no 4 n bits 80 index PRIMARY of table `len`.`teacher` trx id 2142 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 0000000005a6; asc       ;;
 2: len 7; hex 81000000b60110; asc        ;;
 3: len 4; hex 4a61636b; asc Jack;;
 4: len 12; hex e6ba90e7a081e7b3bbe58897; asc             ;;

RECORD LOCKS space id 11 page no 4 n bits 80 index PRIMARY of table `len`.`teacher` trx id 2142 lock_mode X locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000003; asc     ;;
 1: len 6; hex 0000000005a6; asc       ;;
 2: len 7; hex 81000000b6011d; asc        ;;
 3: len 4; hex 4d61726b; asc Mark;;
 4: len 12; hex e5b9b6e58f91e7bc96e7a88b; asc             ;;

---TRANSACTION 2140, ACTIVE 1868 sec
4 lock struct(s), heap size 1128, 4 row lock(s)
MySQL thread id 30, OS thread handle 140241693579008, query id 415 localhost root
TABLE LOCK table `len`.`teacher` trx id 2140 lock mode IX
RECORD LOCKS space id 11 page no 5 n bits 80 index idx_name of table `len`.`teacher` trx id 2140 lock_mode X locks gap before rec
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 4d61726b; asc Mark;;
 1: len 4; hex 80000003; asc     ;;

RECORD LOCKS space id 11 page no 5 n bits 80 index idx_name of table `len`.`teacher` trx id 2140 lock_mode X
Record lock, heap no 5 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 4b696e67; asc King;;
 1: len 4; hex 8000000f; asc     ;;

Record lock, heap no 7 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 5; hex 4b696e6773; asc Kings;;
 1: len 4; hex 80000046; asc    F;;

RECORD LOCKS space id 11 page no 4 n bits 80 index PRIMARY of table `len`.`teacher` trx id 2140 lock_mode X locks rec but not gap
Record lock, heap no 8 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000046; asc    F;;
 1: len 6; hex 000000000840; asc      @;;
 2: len 7; hex 820000008c0110; asc        ;;
 3: len 5; hex 4b696e6773; asc Kings;;
 4: len 6; hex 646f636b6572; asc docker;;

---TRANSACTION 2138, ACTIVE 3520 sec
4 lock struct(s), heap size 1128, 3 row lock(s)
MySQL thread id 26, OS thread handle 140241691940608, query id 375 localhost root
TABLE LOCK table `len`.`teacher` trx id 2138 lock mode IX
RECORD LOCKS space id 11 page no 5 n bits 80 index idx_name of table `len`.`teacher` trx id 2138 lock_mode X
Record lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 5; hex 4a616d6573; asc James;;
 1: len 4; hex 80000009; asc     ;;

RECORD LOCKS space id 11 page no 4 n bits 80 index PRIMARY of table `len`.`teacher` trx id 2138 lock_mode X locks rec but not gap
Record lock, heap no 7 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 80000009; asc     ;;
 1: len 6; hex 00000000083f; asc      ?;;
 2: len 7; hex 010000011a0793; asc        ;;
 3: len 5; hex 4a616d6573; asc James;;
 4: len 6; hex 537072696e67; asc Spring;;

RECORD LOCKS space id 11 page no 5 n bits 80 index idx_name of table `len`.`teacher` trx id 2138 lock_mode X locks gap before rec
Record lock, heap no 5 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 4; hex 4b696e67; asc King;;
 1: len 4; hex 8000000f; asc     ;;

Predicate Locks for Spatial Indexes

​ 从 MySQL5.7 开始 MySQL 整合了 boost.geometry 库以更好的支持空间数据 类型，并支持在在 Spatial 数据类型的列上构建索引，在 InnoDB 内，这个索引和 普通的索引有所不同，基于 R-TREE 的结构，目前支持对 2D 数据的描述，暂不支 持 3D.

​ R-TREE 和 BTREE 不同，它能够描述多维空间，而多维数据并没有明确的数 据顺序，因此无法在 RR 隔离级别下构建 NEXT-KEY 锁以避免幻读，因此 InnoDB 使用称为 Predicate Lock 的锁模式来加锁，会锁住一块查询用到的被称为 MBR(minimum boundingrectangle/box)的数据区域。 因此这个锁不是锁到某个具 体的记录之上的，可以理解为一种 Page 级别的锁。

​ Predicate Lock 和普通的记录锁或者表锁（如上所述）存储在不同的 lock hash 中，其相互之间不会产生冲突。