MySQL锁类型（详解）

锁的分类图，如下：

锁操作类型划分

读锁 : 也称为共享锁 、英文用S表示。针对同一份数据，多个事务的读操作可以同时进行而不会互相影响，相互不阻塞的。
写锁 : 也称为排他锁 、英文用X表示。当前写操作没有完成前，它会阻断其他写锁和读锁。这样就能确保在给定的时间里，只有一个事务能执行写入，并防止其他用户读取正在写入的同一资源。
对于InnoDB引擎，读锁和写锁可以加在表上，或者行上

1.锁定读

对读取的记录加S锁:

select...lock in share mode;
#或
select...for share;#(8.0新增语法)。。

若当前事务执行了该语句，则会给该记录加S锁，并允许别的事务继续获取该记录的S锁，比如别的事务也使用 SELECT... LOCK IN SHAREMODE 语句来读取这些记录

但是不能获取这些记录的X锁，比如别的事务不能直接修改这些记录，会阻塞直到当前事务提交之后将这些记录上的S锁释放掉。

对读取的记录加X锁:

select...for update;

如果当前事务执行了该语句，则会给该记录加X锁，即不允许别的事务获取这些事务S锁，也不允许获取X锁...

MySQL8新特性

在8.0版本中，SELECT ... FOR UPDATE, SELECT .. FOR SHARE 添加NOWAIT、 SKIP LOCKED 语法，跳过锁等待，或者跳过锁定。

通过添加NOWAIT、SKIP LOCKED语法，能够立即返回。如果查询的行已经加锁:
- 那么NOWAIT会立即报错返回
- 而SKIP LOCKED也会立即返回，只是返回的结果中不包含被锁定的行

2.写操作

写操作无非是delete，update，insert

DELETE

底层是先在 B+ 树中定位到这条记录的位置，然后获取这条记录的X锁，再执行 delete操作。
UPDATE
- 情况1: 未修改该记录的键值，并且被更新的列占用的存储空间在修改前后未发生变化。
  
  则在 B+ 树中定位到这条记录的位置，然后获取记录的 X锁，最后在原记录的位置进行修改操作。
- 情况2: 修改了该记录的键值，则相当于在原记录上做 DELETE 操作之后再来一次INSERT操作，加锁操作。需要按照 DELETE 和 INSERT 的规则进行了。

`2.意向锁`

InnoDB 支持多粒度锁，它允许行级锁与表级锁共存，而意向锁就是其中的一种表锁

意向锁的存在是为了协调行锁和表锁的关系
意向锁是一种不与行级锁冲突表级锁 ，这一点非常重要
意向锁是自动创建的，自动声明其上级获取过锁这一动作，轮到时就会有排队权

意向锁分为两种：

意向共享锁: 事务有意向对表中的某些行加共享锁(S锁)

#事务要获取某些行的S锁，必须先获得表的IS 锁。
select column from table ... lock in share mode;

意向排他锁: 事务有意向对表中的某些行加排他锁(X锁)

#事务要获取某些行的X锁，必须先获得表的 IX 锁
select column from table ... for update;

意向锁是由存储引擎自己维护的 ，用户无法手动操作意向锁，在为数据行加共享/排他锁之前，InooDB 会先获取该数据行所在数据表的对应意向锁

意向锁作用

现在有两个事务T1和T2，其中T2试图在该表级别上应用共享或排它锁

如果没有意向锁存在，那么T2就需要去检查各个页或行是否存在锁
如果存在意向锁，那么此时就会受到由T1控制的表级别意向锁的阻塞，T2在锁定该表前不必检查各个页或行锁，而只需检查表上的意向锁。其实就是在更大一级别的空间示意里面是否已经上过锁!
在数据表的场景中，如果我们给某一行数据加上了排它锁，数据库会自动给更大一级的空间，比如数据页或数据表加上意向锁，告诉其他人这个数据页或数据表已经有人上过排它锁了，这样当其他人想要获取数据表排它锁的时候，只需要看是否有人已获取这个数据表的意向排他锁即可

假设事务A获取了某一行的排他锁，并未提交

begin;
select * from teacher where id=6 for update;

事务B想要获取teacher表的读锁，语句如下

begin;
lock tables teacher read;

因为共享锁与排他锁互斥，所以事务B在试图对 teacher 表加共享锁的时候，必须保证两个条件。

当前没有其他事务持有 teacher 表的排他锁
当前没有其他事务持有 teacher 表中任意一行的排他锁

为了检测是否满足第二个条件，事务B必须在确保 teacber 表不存在任何排他锁的前提下，去检测表中的每一行是否存在排他锁。很明显这是一个效率很差的做法，但是有了意向锁之后，情况就不一样了。

总结

意向锁是一个虚拟的锁，只是为了让别的事务知道这里有行级锁所以不能加某些表级锁

`3.自增锁`

在使用MySQL过程中，我们可以为表的某个列添加 AUTO_INCREMENT属性。举例：

CREATE TABLE `teacher` (
     `id` int NOT NULL AUTO_INCREMENT,
     `name` varchar(255) NOT NULL,
     PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

这意味着插入语句时不需要为其赋值，SQL语句修改如下所示

INSERT INTO `teacher` (name) VALUES ('zhangsan'), ('lisi');

#上边的插入语句并没有为id列显式赋值，所以系统会自动为它赋上递增的值，结果如下所示
sql>mysql> select * from teacher;
+----+----------+
| id | name   |
+----+----------+
| 1 | zhangsan |
| 2 | lisi   |
+----+----------+
2 rows in set (0.00 sec)

所有插入数据的方式总共分为三类，分别是:“ Simple inserts ”，“ Bulk inserts ”和“ Mixed-mode inserts ”。

对于上面案例，MySQL中采用了自增锁的方式来实现，自增锁是向含有AUTO_INCREMENT列的表中插入数据时的一种特殊的表级锁，在执行插入语句时加一个AUTO-INC锁，分配递增的值，执行结束后，再把AUTO-INC锁释放掉。

一个事务在持有AUTO-INC锁的过程中，其他事务的插入语句都要被阻塞，可以保证一个语句中分配的递增值是连续的。也正因为此，其并发性不高，当我们向一个有AUTO_INCREMENT关键字的主键插入值的时候，每条语句都要对这个表锁进行竞争，这样的并发潜力其实是很低下的，所以innodb通过 innodb_autoinc_lock_mode的不同取值来提供不同的锁定机制，来显著提高SQL语句的可伸缩性和性能。

#innodb_autoinc_lock_mode=0(传统锁定模式)
所有insert语句都会获得自增锁，这种锁定是全局性的，即它会阻止其他事务同时进行插入操作，直到当前插入完成，即上面例子，并发性差

#innodb_autoinc_lock_mode=1(连续锁定模式)
sql>mysql8之前的默认模式，当执行 INSERT 时，InnoDB 会先检查是否有可用的自增值，如果有，则立即分配该值给新行，然后才加锁

#innodb_autoinc_lock_mode=2(交错锁定模式)
InnoDB 会预先分配一组自增ID（数量由 innodb_autoinc_cache 控制），然后将这些ID分配给后续的插入操作，多个客户端可以同时从预分配的ID池中获取ID并插入新行，从而大大减少了锁等待的时间，但由于多个语句会同时需要数字，所以任何给定插入的行生成的值可能不是连续的

`4.元数据锁（MDL锁）`

MDL 的作用是，保证读写的正确性。比如，如果一个查询正在遍历一个表中的数据，而执行期间另一个线程对这个表结构做变更 ，增加了一列，那么查询线程拿到的结果跟表结构对不上，肯定是不行的。

因此，当对一个表做增删改查操作的时候，加MDL读锁；当要对表做结构变更操作的时候，加 MDL写锁。解决DML和DDL操作之间的一致性问题，不需要显式使用，在访问一个表时会自动加上

2.行级锁

顾名思义，就是锁住页中某一行记录，注意点是 行级锁只在存储引擎层实现，锁的力度小，发生锁冲突概率低，并发度高

缺点是对于锁的开销比较大，加锁会比较慢，容易出现死锁情况

`数据准备`

CREATE TABLE accounts (
    id INT PRIMARY KEY,
    balance DECIMAL(10, 2)
);

INSERT INTO accounts (id, balance) VALUES (1, 1000), (2, 2000);

`记录锁`

记录锁仅仅把一条记录锁上，官方的类型名称为:LOCK_REC_NOT_GAP。比如我们把id值为8的那条记录加一个记录锁如图所示，仅仅是锁住了id值为8的记录，对周围的数据没有影响。

记录锁是有S锁和X锁之分的，称之为 S型(读)记录锁 和 X型(写)记录锁

当一个事务获取了一条记录的读锁后，其他事务可以继续获取该记录的读锁，但不可以继续获取写锁；
当一个事务获取了一条记录的写锁后，其他事务既不可以获取该记录的读锁，也不可以继续获取写锁。

`死锁`

接下来，我们来看一个可能引起死锁的情况，假设事务 D 和事务 E 同时运行，并且它们都试图更新两个账户的余额：

-- 启动事务 D
START TRANSACTION;
-- 获取账户1的排他锁
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;

-- 启动事务 E
START TRANSACTION;
-- 获取账户2的排他锁
SELECT * FROM accounts WHERE id = 2 FOR UPDATE;

-- 事务 D 试图获取账户 2 的排他锁
SELECT * FROM accounts WHERE id = 2 FOR UPDATE;

-- 事务 E 试图获取账户 1 的排他锁
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;

事务D已经获得了账户1的排他锁，而事务E已经获得了账户2的排他锁。
当事务D试图获取账户2的排他锁时，它会被阻塞，同样地，当事务 E 试图获取账户 1 的排他锁时也会被阻塞。这就会形成一个死锁的情况。
InnoDB 会检测到这种情况，并自动解决死锁。它会选择一个事务回滚，以便另一个事务可以继续执行。
可以通过查看 INFORMATION_SCHEMA.INNODB_TRX 表来了解当前的事务状态，包括死锁信息

`间隙锁`

MySQL 在可重复读隔离级别下是可以解决幻读问题的，解决方案有两种

可以使用 MVCC方案解决
也可以采用加锁方案解决。

但是事务在第一次执行读取操作时，那些幻影记录尚不存在，我们无法给这些幻影记录加上记录锁，所以InnoDB提出了一种称之为Gap Locks 的锁，官方的类型名称为： LOCK_GAP ，我们可以简称为 gap 锁（间隙锁）

间隙锁是在行级别的锁定之上的一种扩展，它不仅锁定具体的行的两边，还锁定行之间的间隙
gap锁的提出仅仅是为了防止插入幻影记录而提出的

这种锁定是为了防止其他事务插入新的行到已经被锁定的数据行之间，从而保证了事务的隔离性和一致性。

图中id值为8的记录加了gap锁，意味着 不允许别的事务在id为3记录后的间隙，即不允许（3，15）之间插入新记录

类型

插入意向间隙锁：

插入意向间隙锁告诉其他事务这里即将发生插入操作，因此其他事务不应该在该位置进行插入

普通间隙锁：

执行 SELECT ... FOR UPDATE 或 SELECT ... FOR SHARE 查询时，InnoDB 会在查询范围内的所有数据行上放置锁，并在这些行之间的间隙上放置间隙锁
普通间隙锁用于防止其他事务在已锁定的数据行之间插入新行

举例

-- 有一个表 orders，其中包含 order_id 和 order_amount 字段
CREATE TABLE orders (
    order_id INT AUTO_INCREMENT PRIMARY KEY,
    order_amount DECIMAL(10, 2)
);

INSERT INTO orders (order_amount) VALUES (100), (500), (1000);

现在，我们有两个事务 A 和 B。事务 A 执行一个范围查询：

-- 启动事务 A
START TRANSACTION;

-- 获取订单金额在200 到 600之间的排他锁
SELECT * FROM orders WHERE order_amount BETWEEN 200 AND 600 FOR UPDATE;

-- 事务A在200和600之间的间隙上放置了间隙锁。这意味着其他事务不能在这个范围内插入新的行

示例 2: 插入意向间隙锁

-- 启动事务 B
START TRANSACTION;
-- 尝试插入一个新的订单
INSERT INTO orders (order_amount) VALUES (300);
#事务B将被阻塞，因为它试图在事务A已经锁定的间隙内插入新的行

`临键锁`

官方的类型名称为： LOCK_ORDINARY，我们也可以简称为next-key锁。Next-Key Locks是在存储引擎 innodb 、事务级别在可重复读的情况下使用的数据库锁，innodb默认的锁就是临键锁

Next-Key Locks 是一种组合锁，它同时包含了记录锁和间隙锁。简单来说，会在一个记录上放置一个记录锁，并且在该记录间隙上放置一个间隙锁。

举例

-- 有一个表 orders，其中包含 order_id 和 order_amount 字段
CREATE TABLE orders (
    order_id INT AUTO_INCREMENT PRIMARY KEY,
    order_amount DECIMAL(10, 2)
);
INSERT INTO orders (order_amount) VALUES (100), (500), (1000);

现在，我们有两个事务A和B。事务A执行一个范围查询：

-- 启动事务 A
START TRANSACTION;

-- 获取订单金额在200到600 之间的排他锁
SELECT * FROM orders WHERE order_amount BETWEEN 200 AND 600 FOR UPDATE;
-- 事务A会在 order_amount 为 500 的行上放置一个排他锁，并在200和600之间的所有间隙上放置间隙锁。这意味着其他事务不能在这个范围内插入新的行

现在，事务 B 尝试插入一个新的订单：

-- 启动事务 B
START TRANSACTION;

-- 尝试插入一个新的订单
INSERT INTO orders (order_amount) VALUES (300);
-- 事务 B 将被阻塞，因为它试图在事务 A 已经锁定的间隙内插入新的行

如果您希望避免临键锁，可以将事务隔离级别设置为 READ COMMITTED：

-- 设置事务隔离级别为 READ COMMITTED
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- 启动事务 A
START TRANSACTION;

-- 获取订单金额在 200 到 600 之间的排他锁
SELECT * FROM orders WHERE order_amount BETWEEN 200 AND 600 FOR UPDATE;
-- 在这种情况下，事务 A 仅在匹配的行上放置排他锁，而不会在行之间的间隙上放置间隙锁

`插入意向锁`

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

工作原理：

假设事务 T1 对区间 [10, 20] 之间的所有行以及这个区间的间隙持有 Next-Key Locks。这时，事务 T2 尝试在区间 [10, 20] 内插入一行数据，比如插入 15。

T2 产生插入意向锁：由于 T1 持有该间隙上的锁，T2 无法立即插入数据，但它会在内存中创建一个插入意向锁，表示它想要在间隙 [10, 20] 中插入数据。
T2 等待：T2 的插入操作被阻塞，等待 T1 的事务结束
T1 提交或回滚：当 T1 完成并释放其锁后，T2 的插入意向锁变为有效，T2 可以继续插入数据。

小结：

通过使用插入意向锁，系统可以更好地管理事务之间的等待顺序，减少死锁的可能性
它允许事务声明插入意图，并在等待间隙锁释放的过程中保持一定的灵活性

`页锁`

页锁就是在页的粒度上进行锁定，锁定的数据资源比行锁要多，因为一个页中可以有多个行记录

当我们使用页锁的时候，会出现数据浪费的现象，但这样的浪费最多也就是一个页上的数据行。页锁的开销介于表锁和行锁之间，会出现死锁。锁定粒度介于表锁和行锁之间，并发度一般

加锁的态度划分

乐观锁和悲观锁并不是锁，而是锁的 设计思想，从名字中也可以看出这两种锁是两种看待数据并发的思维方式

①悲观锁

顾名思义，就是很悲观，总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会 阻塞 直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）

比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，当其他线程想要访问数据时，都需要阻塞挂起。Java中 synchronized 和 ReentrantLock 等独占锁就是悲观锁思想的实现

实现方式: 使用行级锁或表级锁，例如可以使用 SELECT...FOR UPDATE或LOCK INSHARE MODE语句来加锁。
悲观锁适合并发冲突多，写多读少的场景。通过每次加锁的形式来确保数据的安全性，吞吐量较低。

-- 读取数据并加锁
SELECT id, name FROM users WHERE id = 1 FOR UPDATE;

-- 执行更新操作
UPDATE users SET name = 'new_name' WHERE id = 1;

秒杀案例

其实就是简单的加锁，解锁，用户发起秒杀请求

检查库存：查询商品库存是否大于0。
获取悲观锁：如果库存大于0，则尝试获取商品对应的悲观锁
扣减库存：在锁定状态下，执行扣减库存的操作。
释放锁：成功扣减库存后，释放悲观锁。
返回结果：向用户返回秒杀成功或失败的消息。

诸如还有微服务中的分布式锁，其实也差不多

②乐观锁

认为对同一数据的并发操作不会总发生，属于小概率事件，不用每次都对数据上锁

但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，不采用锁机制，而是通过程序来实现。在程序上，我们可以采用版本号机制或者CAS机制实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量。

-- 假设有一张用户表 users，包含 id、name 和 version 字段
-- 读取数据
SELECT id, name, version FROM users WHERE id = 1;

-- 更新数据时检查版本号
UPDATE users
SET name = 'new_name', version = version + 1
WHERE id = 1 AND version = current_version;

在Java中 java.util.concurrent.atomic 包下的原子变量类就是使用了乐观锁的一种实现方式：CAS实现的

适用场景

加锁的方式划分

①隐式锁

顾名思义，看不到的锁，简单来说就是在一个事务中执行新插入一条记录操作并不加锁，但是会给该插入操作加隐式锁的结构，对这条插入记录进行保护，防止该记录被其他事务访问

案例

-- session 1:
sql>mysql> begin;
Query OK, 0 rows affected (0.00 sec)
sql>mysql> insert INTO student VALUES(34,"周八","二班");
Query OK, 1 row affected (0.00 sec)
-- session 2
sql>mysql> begin;
Query OK, 0 rows affected (0.00 sec)
sql>mysql> select * from student lock in share mode;   #执行完，当前事务被阻塞
sql>mysql> SELECT * FROM performance_schema.data_lock_waits\G;
*************************** 1. row ***************************
             ENGINE: INNODB
   REQUESTING_ENGINE_LOCK_ID: 140562531358232:7:4:9:140562535668584
REQUESTING_ENGINE_TRANSACTION_ID: 422037508068888
     REQUESTING_THREAD_ID: 64
      REQUESTING_EVENT_ID: 6
REQUESTING_OBJECT_INSTANCE_BEGIN: 140562535668584
    BLOCKING_ENGINE_LOCK_ID: 140562531351768:7:4:9:140562535619104
BLOCKING_ENGINE_TRANSACTION_ID: 15902
      BLOCKING_THREAD_ID: 64
       BLOCKING_EVENT_ID: 6
BLOCKING_OBJECT_INSTANCE_BEGIN: 140562535619104
1 row in set (0.00 sec)

分析

上述insert 语句只是给新插入的那一行上了隐式锁
后面select * 是给全表上读锁
因为后面要给全表记录上锁，所以前面那条insert 语句会将那一行的隐式锁转行为X锁
所以后面的 select语句的 读锁 会和insert 语句生成的X锁冲突,所以select语句等待
如果select语句不是 select * 全表记录 ,而是 select 其他的已存在索引上的等值记录,那么就不会和insert 语句X锁冲突,则可以查询成功

隐式锁的逻辑过程如下：

A. InnoDB目录页中的每条记录中都一个隐含的trx_id字段，这个字段存在于聚簇索引的B+Tree中。

B. 在操作一条记录前，首先根据记录中的trx_id检查该事务是否是活动的事务(未提交或回滚)。如果是活动的事务，首先将隐式锁转换为显式锁 (就是为该事务添加一个锁)

C. 检查是否有锁冲突，如果有冲突，创建锁，并设置为waiting状态。如果没有冲突不加锁，跳到E。

D. 等待加锁成功，被唤醒，或者超时

E. 写数据，并将自己的trx_id写入trx_id字段

如何判断隐式锁是否存在

InnoDB的每条记录中都一个隐含的trx_id字段，这个字段存在于聚集索引的B+Tree中。假设只有主键索引，则在进行插入时，行数据的trx_id被设置为当前事务id；假设存在二级索引，则在对二级索引进行插入时，需要更新所在page的max_trx_id。

因此对于主键，只需要通过查看记录隐藏列trx_id是否是活跃事务就可以判断隐式锁是否存在。对于对于二级索引会相对比较麻烦，先通过二级索引页上的max_trx_id进行过滤，如果无法判断是否活跃则需要通过应用undo日志回溯老版本数据，才能进行准确的判断。

②显式锁

通过特定的语句进行加锁，例如：

#显示加共享锁
select ....  lock in share mode
#显示加排它锁
select ....  for update

其它锁

全局锁

就是对整个数据库实例 加锁。当你需要让整个库处于 只读状态 的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句-全局锁的典型使用 场景 是：做 全库逻辑备份

Flush tables with read lock

死锁

死锁是指两个或多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环。

有 两种解决策略：

直接进入等待，直到超时。这个超时时间可以通过参数innodb_lock_wait_timeout 来设置
另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务（将持有最少行级排他锁的事务进行回滚），让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on，表示开启这个逻辑