锁机制
文章目录
一：MySQL锁的由来与分类
前面说并发问题：脏写、脏读、不可重复读以及幻读问题，而对于这些问题又可以通过调整事务的隔离级别来避免
那为什么调整事务的隔离级别后能避免这些问题产生呢？
因为不同的隔离级别中，工作线程执行SQL语句时，用的锁粒度、类型不同。
1：锁机制的分类
总归说来说去其实就共享锁、排他锁两种，只是加的方式不同，加的地方不同，因此就演化出了这么多锁的称呼
二：共享锁与排他锁
1：共享锁(S锁)
共享锁的意思很简单，也就是不同事务之间不会排斥，可以同时获取锁并执行
⚠️这里所谓的不会排斥，仅仅只是指不会排斥其他事务来读数据，但其他事务尝试写数据时，就会出现排斥性
在MySQL中，我们可以在SQL语句后加上相关的关键字来使用共享锁
# MySQL8.0
select ... for share
# 如果用的是MySQL5.7，使用的是:(8.0不能使)
select ... in share mode
而实际上为数据库设置了不同的事务隔离级别后，MySQL也会对SQL自动加锁，这种形式则被称之为隐式锁。
2：排他锁(X锁)
排他锁也被称之为独占锁，当一个线程获取到独占锁后，会排斥其他线程
如若其他线程也想对共享资源/同一数据进行操作，必须等到当前线程释放锁并竞争到锁资源才行
⚠️ 排他锁并不是只能用于写操作
对于一个读操作，也可以手动的指定为获取排他锁
在MySQL中，可以通过如下方式显式获取独占锁：
select ... for update;
做个小实验
当两个事务同时获取排他锁，尝试读取一条相同的数据时，其中一个事务就会陷入阻塞，直至另一个事务结束才能继续往下执行
但是下述这种情况则不会被阻塞：
而至于为什么不会阻塞的原因，是因为MVCC机制【后面说】
3：锁的释放
MySQL中释放锁的动作都是隐式的，毕竟如果交给咱们来释放，很容易由于操作不当造成死锁问题发生。
因此对于锁的释放工作，MySQL自己来干，就类似于JVM中的GC机制一样，把内存释放的工作留给了自己完成。
但对于锁的释放时机，在不同的隔离级别中也并不相同
二：表级别锁
表锁应该是听的最多的一种锁，因为实现起来比较简单，同时应用范围也比较广泛，几乎所有的存储引擎都会支持这个粒度的锁
表锁顾名思义就是以表作为锁的基础，将锁加在表上，一张表只能存在一个同一类型的表锁
在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操作，自然就会出现问题
比如我刚删了一个表字段，结果另一个事务中又按原本的表结构插入了一条数据，这显然会存在风险
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尝试获取一个表级锁时，就会先看一下表上是否有意向锁
- 如果有的话再判断一下与自身是否冲突：
互斥兼容关系 (排它锁和谁都互斥，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+树，从而做到不影响其他分支上的读写操作。
引入共享排他锁后，究竟是如何实现的这点呢？
在聊之前首先得搞清楚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操作的叶分支中时，依旧会被阻塞。
