1）按锁粒度划分#

这是最常见的一种分类。

2）按锁的读写性质划分#

3）按 InnoDB 行锁实现细分#

InnoDB 的“行锁”其实还可以细分为：

• Record Lock（记录锁）
• Gap Lock（间隙锁）
• Next-Key Lock（临键锁）
• Insert Intention Lock（插入意向锁）

这部分通常是面试重点。

4）总结#

如果面试官问 MySQL 有哪些锁，你可以这样答：

MySQL 的锁可以按粒度分为表锁、行锁、页锁；按性质分为共享锁和排他锁；在 InnoDB 中，行锁又进一步分为记录锁、间隙锁、临键锁和插入意向锁。

一句话总结：

MySQL 锁的本质是并发控制手段，粒度越大并发越低，粒度越小控制越精细。

1）Record Lock（记录锁）#

记录锁就是：

直接锁住某条索引记录本身。

例子

假设表中主键有这些值：

1
1, 6, 8, 12

执行：

1
SELECT * FROM user WHERE id = 6 FOR UPDATE;

如果 id 是主键，并且精确命中一条记录，那么 InnoDB 通常会对 id=6 这一条索引记录加记录锁。

特点

• 只锁住这条记录
• 不锁前后间隙
• 常出现在唯一索引等值命中场景

2）Gap Lock（间隙锁）#

间隙锁是：

锁住两条索引记录之间的“空隙”，但不锁具体记录本身。

它锁的是一个范围内“还没有数据的位置”。

例子

表中已有主键：

1
1, 6, 8, 12

执行：

1
SELECT * FROM user WHERE id = 3 FOR UPDATE;

因为 id=3 这条记录并不存在，所以 InnoDB 可能会锁住区间：

1
(1, 6)

也就是 1 和 6 之间的间隙。

作用

主要是为了防止其他事务在这个间隙里插入新记录，从而避免幻读。

特点

• 锁空隙，不锁现有记录
• 防止插入
• 常见于范围查询或等值查询未命中时

3）Next-Key Lock（临键锁）#

临键锁是：

记录锁 + 间隙锁 的组合

它锁住的是一个“左开右闭”的区间。

例如：

• (1, 6]
• (6, 8]

也就是：

• 锁住前面的间隙
• 也锁住右边那条记录

例子

还是这组数据：

1
1, 6, 8, 12

执行：

1
SELECT * FROM user WHERE id > 5 AND id <= 7 FOR UPDATE;

这里可能锁住：

• (1, 6]
• (6, 8)

或者按具体范围落在相应临键区间上。

通常 MySQL 默认行锁机制就是 Next-Key Lock，尤其在可重复读隔离级别下。

作用

Next-Key Lock 的目标也是：

防止幻读

因为它不仅锁记录，还顺便把前面的间隙锁住了，别人就不能在这个范围偷偷插入新数据。

4）Insert Intention Lock（插入意向锁）#

插入意向锁是：

当事务准备向某个间隙插入记录时，先声明“我想插这里”的一种锁。

它不是说插入已经成功，而是表示：

• 我准备在这个 gap 中插入
• 如果 gap 没被别的锁阻塞，我就继续插

例子

假设某事务 T1 已对间隙 (1,6) 加了 gap lock。 这时事务 T2 想插入 id=4：

1
INSERT INTO user(id) VALUES(4);

那么 T2 会在 (1,6) 上申请插入意向锁，并等待。 如果同时 T3 想插入 id=3，它也会申请插入意向锁。

特点

• 插入意向锁之间不互斥
• 但会和 gap lock / next-key lock 互斥
• 本质上是插入前的等待声明

5）总结这四种锁#

6）一句话总结#

InnoDB 的行锁本质上是“索引锁”，通过记录锁、间隙锁和临键锁组合，既控制并发更新，又解决幻读问题。

1）为什么需要意向锁？#

想象一个问题：

如果事务 A 给表里的某几行加了行锁， 这时事务 B 想给整张表加表锁，MySQL 怎么知道能不能加？

如果没有意向锁，数据库就得：

• 去扫描整张表
• 看每一行是否已经被加锁

这显然效率太低。

所以 InnoDB 引入意向锁，让事务在加行锁之前，先在表级别做一个“声明”。

2）意向锁的本质#

可以把它理解成：

“我后面打算给这张表里的某些行加锁，你先别急着给整张表加互斥锁。”

也就是说，意向锁本质是一种锁的声明机制。

3）意向锁有哪些类型？#

常见有两种：

1
SELECT * FROM user WHERE id = 1 FOR UPDATE;

4）意向锁解决了什么问题？#

它解决的是：

表锁和行锁共存时的快速冲突判断问题。

如果某张表上已经有意向排他锁，那么另一个事务想加表级排他锁时，就能快速知道：

• 表里已经有行锁活动
• 当前不能直接加整表互斥锁

而不必扫描整张表每一行。

5）意向锁之间冲突吗？#

通常：

• 意向锁之间一般不冲突
• 它主要是和表级排他锁冲突

因为它只是“声明”，不是实际锁定某一行数据。

6）不要和插入意向锁混淆#

这两个名字很像，但完全不是一回事。

7）一句话总结#

意向锁是一种表级声明锁，作用是让 InnoDB 能快速判断表锁和行锁是否冲突。

1）悲观锁#

悲观锁认为：

并发冲突很可能发生，所以每次操作数据前都先加锁。

也就是说，它对并发修改持“悲观”态度。

在 MySQL 里的体现

常见悲观锁操作包括：

1
SELECT * FROM user WHERE id = 1 FOR UPDATE;

或者：

1
SELECT * FROM user WHERE id = 1 LOCK IN SHARE MODE;

其中：

• FOR UPDATE 通常加排他锁
• LOCK IN SHARE MODE（新版本推荐 FOR SHARE）加共享锁

这些都属于典型悲观锁思路。

特点

• 安全性高
• 冲突时控制更直接
• 但容易阻塞，影响并发性能

适用场景

适合：

• 冲突概率高
• 数据一致性要求高
• 金融、库存扣减、强一致更新

2）乐观锁#

乐观锁认为：

并发冲突不常发生，所以先不加锁，提交更新时再判断数据是否被别人改过。

它对并发持“乐观”态度。

常见实现方式

通常通过：

• 版本号（version）
• 时间戳（timestamp）

来实现。

例子：版本号方式

表里有字段：

1
id | balance | version

读取数据时拿到：

1
balance = 1000
2
version = 3

更新时带上版本条件：

1
UPDATE account
2
SET balance = 900, version = version + 1
3
WHERE id = 1 AND version = 3;

如果这条 SQL 影响行数为 1，说明没人改过，更新成功。 如果影响行数为 0，说明版本不匹配，数据已经被别人改过，需要重试或报错。

特点

• 不阻塞读写
• 并发性能好
• 但更新冲突时需要业务处理失败重试

适用场景

适合：

• 读多写少
• 并发冲突概率低
• 能接受重试机制
• 应用层自己控制并发一致性

3）两者对比#

4）一句话总结#

悲观锁是“先锁再改”，乐观锁是“先改前提下提交时校验”。

1）死锁是怎么发生的？#

一个经典例子：

1
UPDATE account SET balance = balance - 100 WHERE id = 1;
2
UPDATE account SET balance = balance + 100 WHERE id = 2;

1
UPDATE account SET balance = balance - 50 WHERE id = 2;
2
UPDATE account SET balance = balance + 50 WHERE id = 1;

2）MySQL 遇到死锁后会怎样？#

InnoDB 会检测死锁。 一旦发现死锁，会自动选择一个“代价较小”的事务回滚，并返回错误：

1
Deadlock found when trying to get lock; try restarting transaction

也就是说：

• 不会无限卡死
• 但业务会收到异常，需要处理

3）怎么排查死锁？#

1
SHOW ENGINE INNODB STATUS;

4）如何解决死锁？#

5）面试回答模板#

如果面试官问“遇到过死锁吗，怎么处理”，你可以这么答：

遇到过。一般先通过 SHOW ENGINE INNODB STATUS 查看最近一次死锁日志，定位涉及的事务和 SQL，然后重点分析加锁顺序、索引是否命中、锁范围是否过大。解决上通常会统一加锁顺序、缩短事务、避免大事务和无索引更新，并在业务层对死锁异常做有限重试。

6）一句话总结#

死锁的本质是循环等待，排查要看死锁日志，解决重点是统一加锁顺序、缩小锁范围、缩短事务时间。