深入理解MySQL 锁之从全局锁到死锁检测的问题

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

锁的全景图

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

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

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

这是所有锁的基础逻辑：

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

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

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

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

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

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

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

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

记录锁（Record Lock）

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

-- 精准打击，只锁 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——开启事务并加锁：

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

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

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

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

在第三个窗口执行：

SELECT * FROM performance_schema.data_locks;

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

第三步：分析死锁

SHOW ENGINE INNODB STATUS;

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

死锁：原理与破局

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

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

经典死锁场景

InnoDB 的死锁检测机制

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

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

代码层面的预防策略

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

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

高频问题补充

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

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

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

结论：永远不要在线上高峰期对大表做 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 = ?，不锁行，提交时检查是否被修改过，适合读多写少的场景

总结

到此这篇关于深入理解 MySQL 锁：从全局锁到死锁检测的文章就介绍到这了,更多相关mysql全局锁到死锁检测内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论