MySQL 的锁并不是单一的概念。本文从三个维度对 InnoDB 锁体系进行系统梳理，帮你在实战和面试中建立清晰的知识框架。
锁的全景图
理解 MySQL 锁，可以从三个维度切入：
第一层：锁的粒度——你在哪里加锁？
FLUSH TABLES WITH READ LOCK（全库备份）业务全线停摆，极少手动使用表级锁包下整个楼层搞装修LOCK TABLES 或元数据锁 (MDL)影响整张表，并发能力差行级锁锁住具体的房间UPDATE ... WHERE id = 1InnoDB 的看家本领，并发最高
第二层：锁的兼容性——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 LockREPEATABLE 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 条件）：
- 互斥：资源在一段时间内只能被一个事务锁定占有且等待：事务已持有锁，同时又在请求另一个被其他事务持有的锁不可抢占：事务持有的锁在事务完成前不能被强制释放循环等待：A 等 B，B 等 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 = ?，不锁行，提交时检查是否被修改过，适合读多写少的场景
总结
到此这篇关于深入理解 MySQL 锁：从全局锁到死锁检测的文章就介绍到这了,
