事务02之锁机制

锁机制

一：MySQL锁的由来与分类

前面说并发问题：脏写、脏读、不可重复读以及幻读问题，而对于这些问题又可以通过调整事务的隔离级别来避免

那为什么调整事务的隔离级别后能避免这些问题产生呢？

因为不同的隔离级别中，工作线程执行SQL语句时，用的锁粒度、类型不同。

1：锁机制的分类

总归说来说去其实就共享锁、排他锁两种，只是加的方式不同，加的地方不同，因此就演化出了这么多锁的称呼

二：共享锁与排他锁

最好不要将共享锁和排他锁称作读锁和写锁

1：共享锁(S锁)

共享锁的意思很简单，也就是不同事务之间不会排斥，可以同时获取锁并执行

⚠️这里所谓的不会排斥，仅仅只是指不会排斥其他事务来读数据，但其他事务尝试写数据时，就会出现排斥性

在MySQL中，我们可以在SQL语句后加上相关的关键字来使用共享锁

# MySQL8.0
select ... for share

# 如果用的是MySQL5.7，使用的是:(8.0不能使)
select ... in share mode

🎉 这种通过在SQL后添加关键字的加锁形式，被称为显式锁

而实际上为数据库设置了不同的事务隔离级别后，MySQL也会对SQL自动加锁，这种形式则被称之为隐式锁。

2：排他锁(X锁)

排他锁也被称之为独占锁，当一个线程获取到独占锁后，会排斥其他线程

如若其他线程也想对共享资源/同一数据进行操作，必须等到当前线程释放锁并竞争到锁资源才行

⚠️ 排他锁并不是只能用于写操作

对于一个读操作，也可以手动的指定为获取排他锁

当一个事务在读数据时，获取了排他锁，那当其他事务来读、写同一数据时，都会被排斥

比如事务T1对ID=88的这条数据加了一个排他锁，此时T2来加排他锁读取这条数据，T3来修改这条数据，都会被T1排斥。

在MySQL中，可以通过如下方式显式获取独占锁：

select ... for update;

做个小实验

当两个事务同时获取排他锁，尝试读取一条相同的数据时，其中一个事务就会陷入阻塞，直至另一个事务结束才能继续往下执行

但是下述这种情况则不会被阻塞：

而至于为什么不会阻塞的原因，是因为MVCC机制【后面说】

3：锁的释放

MySQL中释放锁的动作都是隐式的，毕竟如果交给咱们来释放，很容易由于操作不当造成死锁问题发生。

因此对于锁的释放工作，MySQL自己来干，就类似于JVM中的GC机制一样，把内存释放的工作留给了自己完成。

但对于锁的释放时机，在不同的隔离级别中也并不相同

比如在“读未提交RU”级别中，是SQL执行完成后就立马释放锁，而在“可重复读RR”级别中，是在事务结束后才会释放。

二：表级别锁

表锁应该是听的最多的一种锁，因为实现起来比较简单，同时应用范围也比较广泛，几乎所有的存储引擎都会支持这个粒度的锁

表锁顾名思义就是以表作为锁的基础，将锁加在表上，一张表只能存在一个同一类型的表锁

在Innodb中，它的锁机制是基于聚簇索引实现的，当SQL执行时，如果能在聚簇索引命中数据，则加的是行锁，如无法命中聚簇索引的数据则加的是表锁

# 假设在innodb下执行这条sql，无法命中聚簇索引，所以加的表级锁
# 这个表级锁，并不是真正意义上的表锁，是一个“伪表锁”，但作用是相同的，锁了整张表。
select * from person for update

在MyISAM中，因为MyISAM不支持聚簇索引，所以若要在MyISAM引擎中使用表锁，又需要使用额外的语法

-- MyISAM引擎中获取读锁（具备读-读可共享特性）
lock tables table_name read;

-- MyISAM引擎中获取写锁（具备写-读、写-写排他特性）
lock tables table_name write;

-- 查看目前库中创建过的表锁（in_use > 0 表示目前正在使用的表锁）
show open tables where in_use > 0;

-- 释放已获取到的锁
unlock tables;

下面是演示的一个小例子：

MyISAM中，当你加了read读锁后，再尝试加write写锁，就会发现无法获取锁，当前线程会陷入阻塞，反过来也是同理

1：元数据锁(了解)

Meta Data Lock -> 元数据锁，也被简称为MDL锁，这是基于表的元数据加锁

在MySQL5.5 - MySQL7.x之间所有存储引擎的表都会存在一个.frm文件，这个文件中主要存储表的结构的，而MDL锁就是基于.frm文件中的元数据加锁的。

这个锁主要是用于：更改表结构时使用，比如你要向一张表创建/删除一个索引、修改一个字段的名称/数据类型、增加/删除一个表字段等这类情况

因为毕竟当你的表结构正在发生更改，假设此时有其他事务来对表做CRUD操作，自然就会出现问题

比如我刚删了一个表字段，结果另一个事务中又按原本的表结构插入了一条数据，这显然会存在风险

因此MDL锁在加锁后，整张表不允许其他事务做任何操作

2：意向锁

InnoDB引擎是一种支持多粒度锁的引擎，而意向锁则是InnoDB中为了支持多粒度的锁，为了兼容行锁、表锁而设计的

表锁和行锁的兼容性问题

假设一张表中有一千万条数据，现在事务T1对ID=99999的这条数据加了一个行锁，此时来了一个事务T2，想要获取这张表的表级别写锁

写锁必须为排他锁，也就是在同一时刻内，只允许当前事务操作，如果表中存在其他事务已经获取了锁，目前事务就无法满足“独占性”，因此不能获取锁。

由于T1是对ID=99999的数据加了行锁，那T2获取表锁时，是不是得先判断一下表中是否存在其他事务在操作？

因为InnoDB中有行锁的概念，所以表中任何一行数据上都有可能存在事务加锁操作

为了能精准的知道答案，MySQL就得将整张表的1000W条数据全部遍历一次，然后逐条查看是否有锁存在，那这个效率自然会非常的低。

就算能接受一行行的慢点遍历！但实际上不仅仅存在这个问题

还有另外一个致命问题，比如现在MySQL已经判断到了第700行数据，发现前面的数据上都没有锁存在，正在继续往下遍历。

而MySQL是支持并发事务的，也就是MySQL正在扫描后面的每行数据是否存在锁时，万一又来了一个事务在扫描过的数据行上加了个锁怎么办？

比如在第123条数据上加了一个行锁。那难道又重新扫描一遍嘛？这就陷入了死循环，行锁和表锁之间出现了兼容问题。

意向锁，挂牌告知

由于行锁和表锁之间存在兼容性问题，所以意向锁诞生！

意向锁实际上也是一种特殊的表锁，意向锁其实是一种挂牌告知的思想

好比日常生活中的出租车，一般都会有一个牌子，表示它目前是“空车”还是“载客”状态，而意向锁也是这个思想。

比如当事务T1打算对ID=99999这条数据加一个行锁之前，就会先加一个表级别的意向锁

比如目前T1要加一个行级别的读锁，就会先添加一个表级别的意向共享锁(IS)，如果T1要加行级别的写锁，亦是同理(IX)。

此时当事务T2尝试获取一个表级锁时，就会先看一下表上是否有意向锁

• 如果有的话再判断一下与自身是否冲突：
  • 比如表上存在一个意向共享锁，目前T2要获取的是表级别的读锁，那自然不冲突可以获取。
  • 如果T2要获取一个表记的写锁时，就会出现冲突，T2事务则会陷入阻塞，直至T1释放了锁（事务结束）为止。

互斥兼容关系 (排它锁和谁都互斥，IX和S互斥)

3：自增锁(了解)

自增锁，这个是专门为了提升自增ID的并发插入性能而设计的，通常情况下咱们在建表时，都会对一张表的主键设置自增特性

我们在写SQL的时候，通常会对主键设置自增，例如：

create table table_name (
	xx_id not null auto_increment,
    ...
) engine = innodb

当对一个字段设置AUTO_INCREMENT自增后，意味着后续插入数据时无需为其赋值，系统会自动赋上顺序自增的值

现在假设这样的一种场景：

目前表中最大的ID=88，如果两个并发事务一起对表执行插入语句

由于是并发执行的原因，所以有可能会导致插入两条ID=89的数据。

因此这里必须要加上一个排他锁，确保并发插入时的安全性

但也由于锁的原因，插入的效率也就因此降低了，毕竟将所有写操作串行化了。

为了改善插入数据时的性能，自增锁诞生了

自增锁也是一种特殊的表锁，但它仅为具备AUTO_INCREMENT自增字段的表服务，同时自增锁也分成了不同的级别

可以通过innodb_autoinc_lock_mode参数控制：

• innodb_autoinc_lock_mode = 0：传统模式。
• innodb_autoinc_lock_mode = 1：连续模式（MySQL8.0以前的默认模式）。
• innodb_autoinc_lock_mode = 2：交错模式（MySQL8.0之后的默认模式）。

三种插入类型

想要了解自增锁的三种模式，就先要了解MySQL的三种插入类型：

• 普通插入：指通过INSERT INTO table_name(...) VALUES(...)这种方式插入。
• 批量插入：指通过INSERT ... SELECT ...这种方式批量插入查询出的数据。
• 混合插入：指通过INSERT INTO table_name(id,...) VALUES(1,...),(NULL,...)这种方式插入，其中一部分指定ID，一部分不指定。

用一句话来概述自增锁的作用：自增锁主要负责维护并发事务下自增列的顺序

也就是说，每当一个事务想向表中插入数据时，都要先获取自增锁先分配一个自增的顺序值，但不同模式下的自增锁也会有些许不同。

4：全局锁(库锁，了解)

全局锁其实是一种尤为特殊的表锁，其实将它称之为库锁也许更合适，因为全局锁是基于整个数据库来加锁的

加上全局锁之后，整个数据库只能允许读，不允许做任何写操作，一般全局锁是在对整库做数据备份时使用。

flush tables with read lock; # 获取全局锁

unlock tables; # 释放全局锁的命令

将其归纳到表锁范围，因为获取锁以及释放锁的命令都是表锁的命令

三：行锁

1：行锁和表锁之间的关系

一张表就类似于一个生活中的酒店，每个事务/请求就类似于一个个旅客，旅客住宿为了确保夜晚安全，通常都会锁门保护自己。

表锁就类似于一个旅客住进酒店之后，直接把酒店大门给锁了，其他旅客就只能等第一位旅客住完出来之后才能一个个进去，每个旅客进酒店之后的第一件事情就是锁大门，防止其他旅客威胁自己的安全问题。

现在假设酒店门口来了一百位旅客，其中大部分旅客都是不同的房间，因此直接锁酒店大门显然并不合理。

行锁就类似于房间的锁，门口的100位旅客可以一起进酒店，每位旅客住进自己的房间之后，将房门反锁

这显然也能保障各自的人身安全问题，同时也能让一个酒店在同一时间内接纳更多的旅客，“性能”更高。

2：行锁的实现

在MySQL诸多的存储引擎中，仅有InnoDB引擎支持行锁

这是因为InnoDB支持聚簇索引，之前说过，InnoDB中如果能够命中索引数据，就会加行锁，无法命中则会加表锁。

InnoDB会将表数据存储在聚簇索引中，每条行数据都会存储在树中的叶子节点上，因此行数据是“分开的”，所以可以对每一条数据上锁

其他引擎大部分都不支持聚簇索引，表数据都是一起存储在一块的，所以只能基于整个表数据上锁，这也是为什么其他引擎不支持行锁的原因。

3：行锁/记录锁(Record lock)

# 获取行级别临键锁
select * from person where id = 1 lock in share mode;

# 获取行级别排它锁
select * from person where id = 1 for update;

想要使用InnoDB的行锁就是这样写的，如果你的SQL能命中索引数据，那也就自然加的就是行锁，反之则是表锁

4：间隙锁(Gap Lock)

间隙锁是对行锁的一种补充，主要是用来解决幻读问题的。想要理解间隙锁，需要理解啥叫间隙：

间隙锁是如何解决幻读的？

重温下幻读的概念：另外一个事务在第一个事务要处理的目标数据范围之内新增了数据，然后先于第一个事务提交造成的问题

举个例子：

现在要将ID>3的用户密码重置为1234，因此事务T1先查到了ID>3的4、9两条数据并上锁了，然后开始更改用户密码

但此时事务T2过来又插入了一条ID=6、password=7777的数据并提交

等T1修改完了4、9两条数据后，此时再次查询ID>3的数据时，结果发现了ID=6的这条数据并未被重置密码。

回顾下幻读的操作：

为了防止出现安全问题，所以T1在操作之前会对目标数据加锁

在T1事务执行时，这条幻影数据还不存在，因此就会出现一个新的问题：不知道把锁加在哪儿，毕竟想要对ID=6的数据加锁，就是加了个寂寞。

那难道不加锁了吗？肯定得加锁，但怎么加呢？间隙锁应运而生！间隙锁的功能与它的名字一样，主要是对间隙区域加锁，举个例子：

select * from zz_users where user_id = 6 lock in share mode;

ID=6的数据在表中还没有呀，咋加锁呢？

其实这个就是间隙锁，此时会锁定{4~9}之间、但不包含4、9的区域，因为间隙锁是遵循左右开区间的原则

🖊 当对一个不存在的数据加锁后，默认就是锁定前后两条数据之间的区间，当其他事务再尝试向该区间插入数据时，就会陷入阻塞，只有当持有间隙锁的事务结束后，才能继续执行插入操作。

5：临键锁(Next-key Lock)

临键锁是间隙锁的加强版本，或者可以说成是一种由记录锁+间隙锁组成的锁：

RR级别的幻读就是通过临键锁解决的

• 记录锁：锁定的范围是表中具体的一条行数据。
• 间隙锁：锁定的范围是左右开区间，但不包含当前这一条真实数据，只锁间隙区域。

临键锁则是两者的结合体，加锁后，即锁定左开右闭的区间，也会锁定当前行数据

select * from zz_user where user_id = 9 lock in share mode

所以临键锁就是：记录锁【当前这行】 + 间隙锁【没有数据的行】

⚠️ 下面两点需要注意：

• 当原本持有锁的T1事务结束后，T2会执行插入操作，这时锁会被T2获取，当你再尝试开启一个新的事务T3，再次获取相同的临键锁时，是无法获取的，只能等T2结束后才能获取（因为临建锁包含了记录锁）。
• 实际上在InnoDB中，除开一些特殊情况外，当尝试对一条数据加锁时，默认加的是临键锁，而并非记录锁、间隙锁。

6：插入意向锁

实际上插入意向锁是一种间隙锁，这种锁是一种隐式锁，也就是无法手动的获取这种锁

在MySQL中插入数据时，是并不会产生锁的，但在插入前会先简单的判断一下，当前事务要插入的位置有没有存在间隙锁或临键锁

如果存在的话，当前插入数据的事务则需阻塞等待，直到拥有临键锁的事务提交。

当事务执行插入语句阻塞时，就会生成一个插入意向锁，表示当前事务想对一个区间插入数据

当持有原本持有临建锁的事务提交后，当前事务即可以获取插入意向锁，然后执行插入操作

当此时如若又来一个新的事务，也要在该区间中插入数据，那新的事务会阻塞吗？

不会阻塞，可以直接执行插入操作

对于写入SQL都会做一次唯一性检测，如果要插入的数据，与表中已有的数据，存在唯一性冲突时会直接抛出异常并返回。

这也就意味着：如果没抛出异常，就代表着当前要插入的数据与表中数据不存在唯一性冲突，或表中压根不存在唯一性字段，可以允许插入重复的数据。

🖊 能够真正执行的插入语句，绝对是通过了唯一检测的，因此插入时可以让多事务并发执行，同时如果设置了自增ID，也会获取自增锁确保安全性，所以当多个事务要向一个区间插入数据时，插入意向锁是不会排斥其他事务的，从这种角度而言，插入意向锁也是一种共享锁。

四：乐观锁和悲观锁

乐观锁和悲观锁只是思想，不是指具体的锁

• 乐观锁：每次执行都认为只会有自身一条线程操作，因此无需拿锁直接执行。
• 悲观锁：每次执行都认为会有其他线程一起来操作，因此每次都需要先拿锁再执行。

1：乐观锁

编程中的无锁技术，或者说乐观锁机制，一般都是基于CAS思想实现的

在MySQL中则可以通过version版本号+CAS的形式实现乐观锁，也就是在表中多设计一个version字段，然后在SQL修改时以如下形式操作：

update ... set version = version + 1, ... where ... and version = version

也就是每条修改的SQL都在修改后，对version + 1

比如T1、T2两个事务一起并发执行时，当T2事务执行成功提交后，就会对version+1

因此事务T1的version=version这个条件就无法成立，最终会放弃执行，因为已经被其他事务修改过了。

当然，一般的乐观锁都会配合轮询重试机制，比如上述T1执行失败后，再次执行相同语句，直到成功为止

乐观锁更加适用于读大于写的业务场景，频繁写库的业务则并不适合加乐观锁。

因为写操作的并发较高时，就容易导致一个事务长时间一直在重试执行，从而导致客户端的响应尤为缓慢。

2：悲观锁

在每次执行前必须获取到锁，然后才能继续往下执行，而数据库中的排他锁，就是一种典型的悲观锁类型。

... for update;

五：总结

1：各种锁的兼容和互斥

1.1：行级锁对比

1.2：表级锁对比

对于表级锁，咱们只需要关注共享意向锁和共享排他锁即可，其他的大多数为MySQL的隐式锁

2：SX锁

2.1：SMO问题

在SQL执行期间一旦更新操作触发B+Tree叶子节点分裂，那么就会对整棵B+Tree加排它锁

这不但阻塞了后续这张表上的所有的更新操作，同时也阻止了所有试图在B+Tree上的读操作，也就是会导致所有的读写操作都被阻塞，其影响巨大。

MySQL 5.7版本中引入SX锁要解决的问题。

2.2：SX锁

如何解决上面的这个问题呢？

最简单的方式就是减小SMO问题发生时影响的B+树范围，锁定的B+Tree粒度

当发生SMO问题时，就只锁定B+Tree的某个分支，而并不是锁定整颗B+树，从而做到不影响其他分支上的读写操作。

引入共享排他锁后，究竟是如何实现的这点呢？

首先要弄清楚SX锁的特性，它不会阻塞S锁，但是会阻塞X、SX锁

在聊之前首先得搞清楚SQL执行时的几个概念：

• 读取操作：基于B+Tree去读取某条或多条行记录。
• 乐观写入：不会改变B+Tree的索引键，仅会更改索引值，比如主键索引树中不修改主键字段，只修改其他字段的数据，不会引起节点分裂。
• 悲观写入：会改变B+Tree的结构，也就是会造成节点分裂，比如无序插入、修改索引键的字段值。

读操作的执行流程

• ①读取数据之前首先会对B+Tree加一个共享锁。
• ②在基于树检索数据的过程中，对于所有走过的叶节点会加一个共享锁。
• ③找到需要读取的目标叶子节点后，先加一个共享锁，释放步骤②上加的所有共享锁。
• ④读取最终的目标叶子节点中的数据，读取完成后释放对应叶子节点上的共享锁。

乐观写入的执行流程

• ①乐观写入之前首先会对B+Tree加一个共享锁。
• ②在基于树检索修改位置的过程中，对于所有走过的叶节点会加一个共享锁。
• ③找到需要写入数据的目标叶子节点后，先加一个排他锁，释放步骤②上加的所有共享锁。
• ④修改目标叶子节点中的数据后，释放对应叶子节点上的排他锁。

悲观写入的执行流程

• ①悲观更新之前首先会对B+Tree加一个共享排他锁。
• ②由于①上已经加了SX锁，因此当前事务执行过程中会阻塞其他尝试更改树结构的事务。
• ③遍历查找需要写入数据的目标叶子节点，找到后对其分支加上排他锁，释放①中加的SX锁。
• ④执行SMO操作，也就是执行悲观写入操作，完成后释放步骤③中在分支上加的排他锁。

如果需要修改多个数据时，会在遍历查找的过程中，记录下所有要修改的目标节点。

2.3：并发事务冲突分析

对于读操作、乐观写入操作而言，并不会加SX锁，共享排他锁仅针对于悲观写入操作会加

由于读操作、乐观写入执行前对整颗树加的是S锁，因此悲观写入时加的SX锁并不会阻塞乐观写入和读操作

但当另一个事务尝试执行SMO操作变更树结构时，也需要先对树加上一个SX锁，这时两个悲观写入的并发事务就会出现冲突，新来的事务会被阻塞。

当第一个事务寻找到要修改的节点后，会对其分支加上X锁，紧接着会释放B+Tree上的SX锁。这时另外一个执行SMO操作的事务就能获取SX锁啦

虽然一个执行悲观写入的事务，找到了要更新/插入数据的节点后会释放SX锁，但是会对其上级的叶节点（叶分支）加上排他锁，因此正在发生SMO操作的叶分支，依旧是会阻塞所有的读写行为！也就是当一个要读取的数据，位于正在执行SMO操作的叶分支中时，依旧会被阻塞。