深入理解 MySQL 锁：从全局锁到死锁检测

往期博客

深入理解 MySQL 索引：从 B+ 树到索引下推

MySQL 的锁并不是单一的概念。本文从三个维度对 InnoDB 锁体系进行系统梳理，帮你在实战和面试中建立清晰的知识框架。

锁的全景图

理解 MySQL 锁，可以从三个维度切入：

维度	锁的类型	核心目的
粒度划分	全局锁、表级锁、行级锁	控制锁定的数据范围（InnoDB 以行锁为主）
兼容性划分	共享锁 (S)、排他锁 (X)	决定多个事务能否同时操作同一块数据
锁的算法	记录锁、间隙锁、临键锁	决定在 B+ 树的哪个位置加锁

第一层：锁的粒度------你在哪里加锁？

锁级别	类比	对应 SQL 场景	影响
全局锁	封锁整栋大楼，不准进出	`FLUSH TABLES WITH READ LOCK`（全库备份）	业务全线停摆，极少手动使用
表级锁	包下整个楼层搞装修	`LOCK TABLES` 或元数据锁 (MDL)	影响整张表，并发能力差
行级锁	锁住具体的房间	`UPDATE ... WHERE id = 1`	InnoDB 的看家本领，并发最高

第二层：锁的兼容性------S 锁与 X 锁

这是所有锁的基础逻辑：

共享锁（S 锁 / 读锁） ：我能读，你也能读，但大家都别想改。触发方式：SELECT ... FOR SHARE
排他锁（X 锁 / 写锁） ：我要改，谁也别想碰。触发方式：UPDATE / DELETE / SELECT ... FOR UPDATE

需要注意的是，普通的 SELECT 是不加锁的（快照读）。只有显式加锁语句才会触发。

意向锁：表级别的"打招呼"

当你准备给某一行加 X 锁时，MySQL 会先在表级别加一个意向排他锁（IX）。

为什么需要它？想象一张 1.6 亿行的表，如果另一个事务想加表锁，没有意向锁的话，数据库得遍历 1.6 亿行去检查有没有行锁。有了意向锁，只需要看一眼表头就知道了------这是一种空间换时间的策略。

关键特性：意向锁之间是兼容的，意向锁和行锁之间也是兼容的。它唯一不兼容的是表级锁。

第三层：行锁的三种算法------InnoDB 的精华

这是基于 B+ 树的物理锁，也是面试最高频的考点。

记录锁（Record Lock）

精确锁住索引树上的某一个叶子节点。

sql 复制代码

-- 精准打击，只锁 pk_id = 10 这一行
SELECT * FROM t_mqtt_log WHERE pk_id = 10 FOR UPDATE;

间隙锁（Gap Lock）

锁住两个索引记录之间的"缝隙"，不包括记录本身。目的是防止幻读------阻止其他事务往这个缝隙里插入新数据。

类比：在 101 房间和 105 房间之间的走廊上放一个"施工中"的牌子，别人想在 102 插入一个新房间？对不起，走廊被封了。

临键锁（Next-Key Lock）

记录锁 + 间隙锁 的组合，锁住一个范围并且包含记录本身。这是 InnoDB 在 REPEATABLE READ 隔离级别下的默认行锁算法。

锁与索引的核心关系

记住一个准则：MySQL 的锁是加在"索引"上的，而不是加在"行"上的。

即使你建表时没有主键也没有唯一索引，InnoDB 也会在后台自动创建一个隐藏列 RowID 作为聚簇索引。

这意味着：

查询命中主键索引 → 精准的记录锁
没命中索引导致全表扫描 → 锁升级为覆盖全表的 Next-Key Lock
REPEATABLE READ 下间隙锁防止幻读；READ COMMITTED 下基本没有间隙锁

实操：三步看透锁

不需要背书，开两个终端窗口就能直观感受。

第一步：制造"对峙"

窗口 A------开启事务并加锁：

sql 复制代码

BEGIN;
SELECT * FROM t_mqtt_log WHERE pk_id = 10 FOR UPDATE;

窗口 B------尝试修改同一行（会被阻塞）：

sql 复制代码

UPDATE t_mqtt_log SET type = 1 WHERE pk_id = 10;
-- 此时 B 会卡住，等待 A 释放锁

第二步：查看"案发现场"

在第三个窗口执行：

sql 复制代码

SELECT * FROM performance_schema.data_locks;

你会清晰地看到：哪个线程持有锁，锁的是哪棵 B+ 树，是 X 锁还是 GAP 锁，甚至能看到锁的具体 pk_id。

第三步：分析死锁

sql 复制代码

SHOW ENGINE INNODB STATUS;

在 LATEST DETECTED DEADLOCK 一栏，你会看到完整的死锁现场：谁在等谁，谁最后被 MySQL 牺牲掉了。

死锁：原理与破局

死锁的发生需要满足四个必要条件（Coffman 条件）：

互斥：资源在一段时间内只能被一个事务锁定
占有且等待：事务已持有锁，同时又在请求另一个被其他事务持有的锁
不可抢占：事务持有的锁在事务完成前不能被强制释放
循环等待：A 等 B，B 等 A，形成环

经典死锁场景

时间点	事务 A	事务 B
T1	`UPDATE users SET name='A' WHERE id=1;`（拿到 ID=1 的锁）
T2		`UPDATE users SET name='B' WHERE id=2;`（拿到 ID=2 的锁）
T3	`UPDATE users SET name='A2' WHERE id=2;`（阻塞，等待 B 释放 ID=2）
T4		`UPDATE users SET name='B2' WHERE id=1;`（死锁！B 试图拿 ID=1，但 A 持有）

InnoDB 的死锁检测机制

InnoDB 通过 Wait-for Graph（等待关系图） 主动检测死锁：

维护一张锁等待关系图，一旦发现环，立即判定死锁
选择代价最小的事务进行回滚（通常是更新行数最少、Undo Log 最少的那个）
被回滚的事务释放所有锁，另一个事务继续执行
应用程序收到经典报错：Deadlock found when trying to get lock; try restarting transaction

代码层面的预防策略

无法完全杜绝死锁，但以下策略能极大降低概率：

固定访问顺序：所有业务逻辑都按相同顺序操作资源（先 ID=1 再 ID=2），从根源上打破循环等待
大事务拆小：事务执行时间越长，持有锁的时间越长，撞车概率越大
善用索引：没命中索引时锁会升级（Next-Key Lock 甚至锁全表），锁范围越大，死锁概率越高
降低隔离级别：如果业务允许，从 RR 降到 RC 可以消灭大部分间隙锁，减少死锁

高频问题补充

元数据锁（MDL）------线上事故高发区

MDL 不是加在数据上的，而是加在表结构上的。一个典型的灾难场景：

事务 A 执行了一个慢查询 SELECT（未结束），持有 MDL 读锁
你执行 ALTER TABLE 加字段，申请 MDL 写锁，被 A 阻塞
之后所有新的 SELECT 都会被这个 ALTER TABLE 堵住
连接池瞬间爆炸，服务雪崩

结论：永远不要在线上高峰期对大表做 ALTER TABLE，除非你明确评估了 MDL 的影响。

自增锁（AUTO-INC Locks）

对于高并发插入场景（比如 t_mqtt_log 每秒插入几千次），所有事务都要抢下一个自增 ID。InnoDB 通过自增锁来协调，关键调优参数是 innodb_autoinc_lock_mode：

0（传统模式）：语句级锁，并发最差
1（连续模式）：简单插入用轻量锁，批量插入用语句级锁（MySQL 5.x 默认）
2（交错模式）：完全并发，性能最好，但批量插入的自增值可能不连续（MySQL 8.0 默认）

悲观锁 vs 乐观锁

这是业务逻辑层面的锁策略选择：

悲观锁 ：SELECT ... FOR UPDATE，先占位再干活，适合写冲突频繁的场景
乐观锁 ：通过版本号控制，UPDATE ... SET version = version + 1 WHERE id = 1 AND version = ?，不锁行，提交时检查是否被修改过，适合读多写少的场景

总结

知识点	核心要点
锁粒度	全局锁 > 表级锁 > 行级锁，InnoDB 以行锁为主
S 锁 / X 锁	共享锁允许并发读，排他锁独占读写
意向锁	表级标记，避免加表锁时逐行检查
记录锁	精确锁住索引上的一条记录
间隙锁	锁住记录间的缝隙，防止幻读
临键锁	记录锁 + 间隙锁，InnoDB 默认行锁算法
锁加在索引上	没命中索引 → 锁升级，范围越大死锁概率越高
死锁检测	Wait-for Graph 检测环，回滚代价最小的事务
MDL	表结构锁，高峰期 ALTER TABLE 可致服务雪崩