8.4. 意向锁

但是在上面的例子这里头有两个问题：
如果我们想对大楼整体上 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 锁是兼容的。
我们画个表来看一下表级别的各种锁的兼容性：

锁的组合性：

8.5.MySQL 中的行锁和表锁

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

8.5.1. 其他存储引擎中的锁

对于 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 的细节，详情可以参考文档。

8.5.2. InnoDB 存储引擎中的锁

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

8.5.2.1. 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。

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

间隙锁实质上是对索引前后的间隙上锁，不对索引本身上锁。
会话 1 开启一个事务，执行

begin;
update teacher set domain ='Spring' where name='James';

会对([‘Jack’,1],[‘James’,9])之间, ([‘James’,9], [‘King’,15])之间进行上锁。

(上图有错误，Jack 下应该为 1)
如图中为[‘James’,9]的记录加了 gap 锁，意味着不允许别的事务在这条记录前后间隙插入新记录。

begin;
insert into teacher value(22,'Jahes','docker');

为什么不能插入？因为记录（22,‘Jahes’）要 插入的话，在索引 idx_name 上，
刚好落在([‘James’,9], [‘King’,15])之间，是有锁的，当然不允许插入。
但是当 SQL 语句变为：insert into teacher value(70,‘Kings’,‘docker’);能插入吗？
当然能，因为（70,‘Kings’）这条记录不在被锁的区间内。

思考题
现在有表，表中有记录如下：

CREATE TABLE test1 (
id int(1) NOT NULL AUTO_INCREMENT, number int(1) NOT NULL COMMENT ‘数字’, PRIMARY KEY (id), KEY number (number) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
INSERT INTO test1 VALUES (1, 1);
INSERT INTO test1 VALUES (5, 3);
INSERT INTO test1 VALUES (7, 8);
INSERT INTO test1 VALUES (11, 12);

开启一个事务

SELECT * FROM test1 WHERE number = 3 FOR UPDATE;

开启另外一个事务：

INSERT INTO test1 (id, number) VALUES (2, 1); # 阻塞
INSERT INTO test1 (id, number) VALUES (3, 2); # 阻塞
INSERT INTO test1 (id, number) VALUES (6, 8); # 阻塞
INSERT INTO test1 (id, number) VALUES (8, 8); # 正常执行
INSERT INTO test1 (id, number) VALUES (9, 9); # 正常执行
INSERT INTO test1 (id, number) VALUES (10, 12); #

问题：为什么（6，8）不能执行，（8，8）可以执行?
解决思路：画一个 number 的索引数据存放的图，然后根据间隙锁的加锁方
式，把锁加上，就能很快明白答案。更详细的的解答，看
http://bbs.xiangxueketang.cn/question/1118。
Next-Key Locks

有时候我们既想锁住某条记录，又想阻止其他事务在该记录前边的间隙插入
新记录，所以 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 的存在，相当于加了一个隐式锁。
这样的话，隐式锁就起到了延迟生成锁的用处。这个过程，我们无法干预，是由引擎自动处理的，对我们是完全透明的，我们知道下就行了。

8.5.2.3. 锁的内存结构

所谓的锁其实是一个内存中的结构，在事务执行前本来是没有锁的，也就是说一开始是没有锁结构和记录进行关联的，当一个事务想对这条记录做改动时，首先会看看内存中有没有与这条记录关联的锁结构，当没有的时候就会在内存中生成一个锁结构与之关联。比方说事务 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 中的哪一种。
• 锁类型：表锁还是行锁，行锁的具体类型。
  其他一些和锁管理相关的数据结构，比如哈希表和链表等。
  基本上来说，同一个事务里，同一个数据页面，同一个加锁类型的锁会保存在一起。

8.6. 查看事务加锁的情况

可以通过

show engine innodb status\G

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

show variables like 'innodb_status_output_locks';

我们需要设置为 ON，

set global innodb_status_output_locks = ON;

然后开启事务，并执行语句

begin;
select * from teacher where name > 'King' and name < 'Mark' and domain !=
'MySQL' order by name desc for update;

再执行 show engine innodb status\G，会显示：

这样就显示的很清楚了。

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

RECORD LOCKS space id 33 page no 4 n bits 72 index idx_name of table
`mysqladv`.`teacher` trx id 12852 lock_mode X locks gap before rec

表示一个内存中的锁结构，
space id 33：表空间 id 为 33；
page no 3：页编号为 4；
index PRIMARY：对应的索引是 idx_name；
lock_mode X locks gap before rec：存放的是一个 X 型的 gap 锁

表示的加锁记录的详细信息
3 .

RECORD LOCKS space id 33 page no 4 n bits 72 index idx_name of table
`mysqladv`.`teacher` trx id 12852 lock_mode X

表示一个内存中的锁结构，
space id 33：表空间 id 为 33；
page no 3：页编号为 4；
index PRIMARY：对应的索引是 idx_name；
lock_mode X：存放的是一个 X 型的 next-key 锁
4、如果是记录锁，则会显示“lock_mode X locks rec but not gap”