第三世界的妖孽都说锁是 MySQL 面试题里的“照妖镜”，但只有真正被线上事故怼过脸的人，才知道这玩意儿不只是拿来考人的。前阵子我们生产库半夜突然出现大面积写入超时，应用侧疯狂报警，我登录数据库一看，FLUSH TABLES WITH READ LOCK 整整齐齐挂在进程列表里，整个实例被锁成了“只读状态”，所有业务写请求全部堵在入口，那个场面，经历过一次就再也不想经历第二次。
MySQL 锁机制这东西，平时安安静静躺在那，你感受不到它的存在，可一旦锁冲突、锁等待、死锁这些问题冒出来，它能让一个健壮的业务系统瞬间瘫痪。很多人对锁的理解停留在“全局锁锁全库、表锁锁整表、行锁锁一行”这种表面层次，但真要回答“为什么备份要加全局锁”“为什么明明只更新一行还会锁表”“为什么主键查询也会产生间隙锁”，就卡壳了。
这篇东西我打算从全局锁一路拆到行级锁，把每类锁的原理、触发场景、互相之间的关系，以及我最常遇到的线上排查案例全部摊开来讲。无论你是刚入门的后端开发、想搞懂锁原理的 DBA，还是正在备战面试的候选人，我都尽量做到让这篇文章读完能直接用到生产环境。
1. 从一次备份事故说起：锁不只是面试题
1.1 一次“全库只读”事故的现场还原
那天凌晨两点多，业务流量虽然处于低谷，但依然有持续不断的订单写入。我接到报警后第一时间连上数据库执行了 SHOW PROCESSLIST，发现大量 UPDATE、INSERT 语句的状态是 Waiting for global read lock，而最前面的一条会话在执行 FLUSH TABLES WITH READ LOCK。
这条语句是系统里一个自动化备份脚本发出来的。这个脚本为了拿到一致性备份，会在备份开始时对整个实例加一把全局读锁，然后调用 mysqldump 去导出数据，导完再释放。按理说这个过程也就几十秒，但问题是当时有一个大查询长时间占着 CPU，导致备份任务整体执行时间被拉长，而 FLUSH TABLES WITH READ LOCK 一旦成功加上，后续所有写操作全部排队等待，数据库的写入链路等于被一把锁直接截断。
我当时做的第一件事是 KILL 掉那个 FLUSH TABLES WITH READ LOCK 会话，让业务先恢复，然后检查备份脚本为什么会选在这个时间点执行全库加锁。
这个事故暴露出的问题很典型：很多人知道全局锁存在，但不知道它锁的是什么、什么时候会锁、锁了之后会发生什么。这里埋伏了一个必须搞清楚的核心概念，MySQL 的全局锁并不是“锁住所有数据”那么简单，而是通过封锁所有写操作来保证备份期间数据的一致性。
1.2 锁的本质：并发控制的手段
数据库的核心价值有两个：存储数据和读写数据。读写数据就会遇到并发问题，多个会话同时操作同一份数据时，如果没有任何约束，就会出现脏读、幻读、不可重复读、更新丢失这类问题。锁的本质就是让并发操作在必要时“排队”，牺牲部分并行能力来换取数据的一致性和完整性。
我经常用一个很生活化的类比来解释锁：公共厕所的隔间。每个隔间就是一份数据资源，每个人就是一个事务。行锁相当于你进了某个隔间并且锁了门，别人只能等这个隔间空出来；表锁相当于整排隔间全被你包了，其他人想用任何一个隔间都得等你出来；全局锁更夸张，直接封了整个厕所，男女厕全部停止使用，想进都不行。
这个类比能解释 MySQL 锁机制里 90% 的行为。锁的范围越大，并发能力越低，但实现越简单、一致性越容易保证；锁的范围越小，并发能力越高，但实现越复杂、死锁风险也越高。
1.3 MySQL 锁机制的家族图谱
按锁的粒度划分，MySQL 的锁可以分成三个层级：全局锁、表级锁、行级锁。全局锁锁的是整个实例，表级锁锁的是整张表，行级锁锁的是表中的某一行记录。这三者不是相互独立的存在，它们之间有协作机制，比如意向锁就是表级锁和行级锁之间的“通信桥梁”。
按锁的模式划分，又可以分为共享锁（读锁，S）、排他锁（写锁，X）、意向共享锁（IS）、意向排他锁（IX）。共享锁和共享锁之间可以兼容，意味着多个事务可以同时读同一份数据；排他锁和任何锁都不兼容，意味着只要有人持有写锁，其他人既不能写也不能读（除非走 MVCC 快照读）。
按锁的实现方式划分，行级锁又可以分为记录锁（Record Lock）、间隙锁（Gap Lock）、临键锁（Next-Key Lock）。这三种锁是 InnoDB 引擎能实现可重复读隔离级别、解决幻读问题的基石。
后面的内容我会沿着“全局锁 → 表级锁 → 行级锁”这条主线逐一拆解，最后再讲死锁和监控排查手段。这条路走通了，你对 MySQL 并发控制的理解会有一个质的提升。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 全局锁：最霸道也最危险的锁
2.1 FTWRL 到底做了什么
全局锁对应的命令是 FLUSH TABLES WITH READ LOCK，通常缩写为 FTWRL。这条命令执行后，MySQL 会做以下几件事：关闭所有打开的表、获取全局读锁、让整个实例处于只读状态。
在 FTWRL 生效期间，以下操作全部会被阻塞：INSERT、UPDATE、DELETE、ALTER TABLE、DROP TABLE、REPAIR TABLE 等所有写操作，以及 FLUSH TABLES 这类需要获取写锁的管理操作。更严格地说，只要是需要获取排他锁的操作，全部排队等待。
那读操作呢？普通的 SELECT 还能执行，因为共享锁和共享锁兼容。但这里有个容易忽略的坑：如果你在事务里执行了 SELECT ... FOR UPDATE 或者 SELECT ... LOCK IN SHARE MODE，这些语句是需要获取排他锁或共享锁的写意向的，同样会被阻塞。也就是说，FTWRL 锁住的不是“所有读”，而是“所有写”以及“带锁的读”。
FTWRL 有一个配套命令是 UNLOCK TABLES，执行后释放全局读锁。另外，会话断开连接时，这个锁也会自动释放，这就是为什么我在事故现场直接 KILL 会话就能恢复业务。
2.2 为什么备份需要全局锁
很多人会问：为什么备份数据库要锁全库？备份期间的写入操作可能会让备份文件里的数据不一致。举个例子：你备份表 A 的时候，表 A 里的用户数据是完整的；但备份到一半，应用往表 B 里写入了一条和表 A 关联的订单数据。最终备份出来的结果里，表 A 的数据和表 B 的数据在时间线上不一致，恢复之后就会产生逻辑错乱。
FTWRL 的思路很简单粗暴：备份期间不允许任何写入，这样所有表的数据都保持在同一个时间点，备份自然就是一致的。
但这个方法在线上环境用起来很痛苦。如果数据量大，备份要跑十几分钟甚至更久，那就意味着整个业务在这段时间内完全不可写，这在绝大多数互联网业务中是不可接受的。
InnoDB 引擎支持 mysqldump --single-transaction，这个参数利用 MVCC 机制，在备份开始时开启一个一致性快照，后面的备份过程都在这个快照上读取数据，不需要锁全库。但要注意，--single-transaction 只对 InnoDB 表有效，MyISAM 表依然需要加锁才能保证一致性。
MySQL 8.0 里还提供了 LOCK INSTANCE FOR BACKUP，这是实例级备份锁，粒度更轻，只阻塞 DDL，不阻塞 DML，适合热备份工具使用。
2.3 全局锁的典型使用场景与风险控制
全局锁在线上最典型的使用场景就是逻辑备份，以及少数需要在无写入状态下做数据迁移的场景。日常业务开发中，几乎不应该主动使用 FTWRL。
如果你真的需要执行全局锁操作，必须做好以下风险控制：
- 选择业务低谷期执行，比如凌晨三四点，并且设置超时时间
- 在监控平台上配置会话持续时间告警，一旦超过阈值立即通知
- 备份脚本里要加自动释放锁的逻辑，防止异常退出后锁未释放
- 优先使用
--single-transaction或专业的物理备份工具，如 Percona XtraBackup
我还想强调一个细节：FTWRL 在执行过程中，需要先关闭所有表，这本身就需要获取表的元数据锁。如果有长事务正持有表的 MDL，FTWRL 也会排队等待，而不是立即拿到全局锁。这就意味着：即使你想用全局锁做备份，也可能被业务侧的长事务反向阻塞住，导致备份迟迟无法启动。
全局锁这个主题，表面上很简单，其实暗流涌动。理解了它的原理和边界，你才算真正迈入 MySQL 锁世界的门槛。
3. 表级锁：显式表锁与元数据锁
3.1 表锁：最古老也最直接的存在
表级锁是 MySQL 最早支持的锁粒度，MyISAM 引擎只支持表锁。表锁的语义很简单：给整张表加锁，锁期间其他会话不能写（如果是写锁）甚至不能读（如果是写锁）这张表。
表锁显式使用的方式是：
sql复制LOCK TABLES table_name READ; -- 加读锁
LOCK TABLES table_name WRITE; -- 加写锁
UNLOCK TABLES; -- 释放锁
读锁是共享锁，多个会话可以同时持有读锁；写锁是排他锁，持有写锁期间，其他会话的读和写都会被阻塞。
在 InnoDB 成为默认引擎之后，LOCK TABLES 的使用场景已经大幅缩减，原因很简单：InnoDB 支持行级锁，本身就能以更细的粒度处理并发控制，不需要用表锁这种粗粒度方案来保证一致性。而且 LOCK TABLES 与 InnoDB 的事务机制存在一些兼容性问题，MySQL 官方文档也不建议在 InnoDB 表上使用显式表锁。
但表锁并没有完全退出历史舞台。ALTER TABLE 这类 DDL 操作在执行期间，MySQL 会通过元数据锁（MDL）来确保表结构不被并发修改，这个机制同样属于表级锁的范畴。
3.2 元数据锁（MDL）：DDL 与 DML 之间的隐形协调者
元数据锁是 MySQL 5.5 引入的机制，全称是 Metadata Lock，简称 MDL。它的作用是保护表结构元数据，防止一个会话在修改表结构的同时，另一个会话正在写入数据，造成不可预期的结果。
MDL 的加锁规则是这样的：任何会话在访问一张表之前，都需要获取这张表的 MDL 读锁；执行 ALTER TABLE、DROP TABLE 这类 DDL 操作时，需要获取 MDL 写锁。MDL 读锁之间是兼容的，MDL 写锁与任何锁都不兼容。
这个机制在日常工作中引发的麻烦非常多。举个真实例子：你执行了一条 ALTER TABLE users ADD COLUMN age INT，正常情况下几秒钟就能完成。但如果此时有一个事务开启了但迟迟未提交，并且它刚才访问过 users 表，那么这个事务就一直持有 users 表的 MDL 读锁。你的 DDL 需要 MDL 写锁，就得排队等待这个事务结束。
问题在于：如果这个事务一直不提交（比如应用层忘记提交、连接池里的空闲连接占了事务不释放），你的 DDL 就会一直卡在 Waiting for table metadata lock 状态。更可怕的是，从你开始等待的那一刻起，后续所有访问 users 表的新请求，不管是读还是写，都会被阻塞在这个 DDL 后面排队，因为它们都需要获取 MDL 读锁，而 MDL 写锁正在等待队列中。
这就是我常说的“一辆车堵死一条街”的经典场景。出现这个状态时，优先要找到源头事务并 KILL 掉，而不是盲目重启数据库。
3.3 意向锁：表锁与行锁之间的桥梁
意向锁是一个容易被忽略但极其重要的设计。它的作用是在表级别记录当前表里是否有人持有行级锁，方便表级锁与行级锁之间的快速冲突检测。
假设没有意向锁：事务 A 给 users 表的某一行加了行级排他锁，此时事务 B 想给 users 表加表级写锁，MySQL 就需要扫描表中的每一行，检查是否有人持有行锁，这个扫描成本是无法接受的。
意向锁的引入解决了这个问题。事务 A 在加行级锁之前，会先给 users 表加上意向排他锁（IX），表级锁的持有者只需要检查表上是否已有意向锁，就能快速判断能否加表级锁。
意向锁的兼容性规则如下：
- 意向共享锁（
IS）与意向共享锁、意向排他锁兼容 - 意向排他锁（
IX）与意向共享锁、意向排他锁兼容 - 表级共享锁（
S）与意向共享锁兼容，与意向排他锁不兼容 - 表级排他锁（
X）与任何意向锁都不兼容
说白了，意向锁本身不阻塞任何请求，它只是“打个招呼”告诉后来者：这表里已经有人持有了行级锁，你自己掂量能不能加表级锁。意向锁让 InnoDB 在同时支持行锁和表锁的场景下，依然能高效地完成冲突检测，这个设计非常巧妙。
3.4 一个 DDL 阻塞问题的排查实录
我再分享一个具体案例。有次一个同事反馈，某张表的 UPDATE 语句全部超时。我 SHOW PROCESSLIST 后发现，大部分会话的状态是 Waiting for table metadata lock，而队首是一个 ALTER TABLE 语句，同样卡住。
排查思路分三步：
第一步，找到持有 MDL 读锁的源头会话。在 MySQL 5.7 里可以执行：
sql复制SELECT * FROM performance_schema.metadata_locks;
SELECT * FROM performance_schema.threads;
metadata_locks 表里能看到锁的持有者（OWNER_THREAD_ID）和锁类型。
第二步，把 OWNER_THREAD_ID 关联到 threads 表，找到对应会话的 PROCESSLIST_ID。
第三步，判断这个会话是否可以安全终止。如果是一个长时间运行且无实际作用的空闲事务，直接 KILL 掉。
当时查到的是一个连接池里的连接，开启事务后执行了一条 SELECT，然后事务一直未提交，应用侧也再没使用这个连接。这种“僵尸事务”在大型应用里非常常见，也是 MDL 阻塞的头号元凶。从那之后，我在团队里定了一条规矩：监控指标里必须包含 MDL 锁等待时长，一旦超过阈值立即告警。
4. 行级锁：InnoDB 的看家本领
4.1 三种行锁：Record Lock、Gap Lock、Next-Key Lock
InnoDB 的行级锁不是“一整行”那么简单，它有三种形态：记录锁（Record Lock）、间隙锁（Gap Lock）、临键锁（Next-Key Lock）。
- 记录锁（Record Lock）：锁定索引记录本身。注意是“索引记录”，不是“数据行”。InnoDB 的表中数据都是按索引组织的，即使没有显式定义主键，也会有一个隐式的 rowid 作为聚簇索引。所以记录锁实际上锁的是聚簇索引上的记录。
- 间隙锁（Gap Lock）：锁定一个范围，但不包含范围内的具体记录。间隙锁的作用是防止其他事务在范围内插入新记录，从而避免幻读。
- 临键锁（Next-Key Lock）：记录锁和间隙锁的组合，既锁住记录本身，又锁住记录前面的间隙。这是 InnoDB 在可重复读隔离级别下的默认行锁策略。
文字描述比较抽象，我结合一个具体的例子来说明。假设表 t 的 id 列有值 1、3、5、7，那么在 RR（可重复读） 隔离级别下，执行 SELECT * FROM t WHERE id = 5 FOR UPDATE 时，会加 Next-Key Lock，锁定的范围是 (3, 5]，也就是说记录 5 本身被锁住，3 到 5 之间的间隙也被锁住，其他事务无法在这个间隙中插入 id=4 的新记录。
4.2 等值查询和范围查询的加锁差异
这是面试里最高频的一个考点，也是实际排查中最容易让人困惑的地方。我分别举例说明。
等值查询 + 唯一索引：
如果 id 是主键或唯一索引，执行 SELECT * FROM t WHERE id = 5 FOR UPDATE：
- 记录存在：只加记录锁，锁住 id=5 这一条记录。因为唯一索引能确定唯一记录，不需要锁间隙。
- 记录不存在：加间隙锁。此时需要锁定
(3, 5)这个间隙，防止其他事务插入 id=4 或 id=5 的记录（id=5 是唯一索引，如果插入成功，当前查询就可能读到，产生幻读）。
等值查询 + 普通索引：
如果查询条件是普通索引列 name = '张三'，即使结果只匹配一条记录，由于普通索引不唯一，InnoDB 无法确定是否还有其他 name='张三' 的记录可能存在，因此会加上 Next-Key Lock，范围是 (上一个值, '张三']，同时锁定记录本身和它前面的间隙。
范围查询：
执行 SELECT * FROM t WHERE id > 3 AND id < 7 FOR UPDATE，InnoDB 会对扫描到的索引范围加上 Next-Key Lock。具体来说，会锁住 3 到 7 之间所有存在的记录，以及它们之间的间隙。这意味着其他事务无法插入 id 在 (3, 7) 范围内的任何新记录。
这就是间隙锁的“破坏力”所在：它锁住的是范围，而不是某条具体记录。高并发下如果频繁使用范围查询加锁，很容易让插入吞吐量大幅下降。
4.3 唯一索引、非唯一索引、无索引的锁行为
再补充一个重要的区分维度：查询条件是否走索引、走什么索引，直接决定了加锁范围。
- 走聚簇索引（主键）：锁的是聚簇索引上的记录。
- 走二级索引：InnoDB 会先锁二级索引记录，然后回表锁聚簇索引记录。两个索引上的记录都被锁定。
- 无索引或索引失效：这是一个深坑。如果
SELECT ... FOR UPDATE的查询条件没有命中任何索引，InnoDB 会扫描聚簇索引的所有记录，对每一条记录都要加上锁。本质上相当于锁全表，但 MySQL 层面并没有给出“锁表”的明确提示，而是以海量的行锁形式存在于内存中。
我曾经排查过一个线上问题：某团队对一张大表执行 UPDATE ... WHERE status = 0，status 列没有索引，执行时把整张表几十万行全部加了行锁，导致后续所有写入和更新全部阻塞。排查结果让人哭笑不得：执行人以为只是更新几行数据，实际效果和锁表没区别。
所以，任何 DELETE 或 UPDATE 操作，务必确认 WHERE 条件是否命中索引。用 EXPLAIN 看一下执行计划，type 为 ALL 或者 key 为 NULL，就要警惕了。
4.4 隔离级别对锁行为的影响
MySQL 默认隔离级别是 REPEATABLE READ，在这个级别下，InnoDB 使用 Next-Key Lock，可以完全避免幻读。但如果你把隔离级别降到 READ COMMITTED，InnoDB 会大量减少间隙锁的使用，只在个别场景下（比如外键约束检查）才使用间隙锁。
这就意味着：降低隔离级别能减少锁冲突，提升并发性能，代价是会引入不可重复读和幻读问题。对于绝大多数业务场景，幻读带来的风险远大于性能提升，所以我不建议随意调整隔离级别。如果有并发瓶颈，优先从索引优化和事务设计入手，而不是一上来就降低隔离级别。
4.5 行锁的加锁时机与释放时机
行锁是在事务执行过程中逐步获取的，不是开启事务时就全部加好。当一个事务执行了 UPDATE、DELETE、SELECT ... FOR UPDATE 等语句，涉及的记录会被加上对应的锁，直到事务提交或回滚时统一释放。
这个特性衍生出一个铁律：事务要尽量短，锁要尽量少。长事务意味着锁长时间不释放，会阻塞其他事务，甚至引发级联等待，最终拖垮整个实例。
另外一个常见的误区是：ROLLBACK 之后锁是否立即释放？答案是：只有事务完全回滚结束，锁才会释放。在回滚过程中，已经获取的锁会一直持有，直到回滚完成。具体到 InnoDB 的实现，回滚需要根据 undo log 逐条恢复数据，这个过程本身可能很慢，所以长事务的回滚也是一个巨大的锁源头。
5. 死锁：当两个事务互不相让
5.1 死锁发生的四个必要条件
死锁的经典定义是：两个或多个事务各自持有对方的资源锁，同时等待对方释放资源，形成循环等待，导致事务永远无法继续。
死锁的发生需要同时满足四个条件：
- 互斥条件：资源只能被一个事务独占
- 持有并等待：事务持有至少一个资源，同时等待获取其他资源
- 不可剥夺：事务持有的资源不能被其他事务强行抢占
- 循环等待：多个事务形成等待环
这四个条件缺一不可。InnoDB 无法完全避免死锁的发生，只能通过检测机制发现死锁并强制回滚其中一个事务。
5.2 两个真实的死锁案例
案例一：两个事务互相更新
事务 A：
sql复制UPDATE t SET val = val + 1 WHERE id = 1;
UPDATE t SET val = val + 1 WHERE id = 2;
事务 B：
sql复制UPDATE t SET val = val + 1 WHERE id = 2;
UPDATE t SET val = val + 1 WHERE id = 1;
如果事务 A 先拿到 id=1 的锁，事务 B 先拿到 id=2 的锁，接着 A 等 id=2、B 等 id=1，死锁形成。InnoDB 检测到死锁后，会回滚其中一个小事务（通常是被判定为回滚代价较小的事务），并抛出死锁错误，应用程序需要捕获这个错误并重试。
案例二：间隙锁引起的死锁
更隐蔽的死锁来自间隙锁。事务 A 执行：
sql复制SELECT * FROM t WHERE id BETWEEN 10 AND 20 FOR UPDATE;
锁定了 (10, 20) 范围内的记录和间隙。事务 B 在另一个事务里插入 id=15 的记录，需要插入意向锁，但又与 A 的间隙锁冲突，于是等待。此时如果事务 A 又试图插入一条 id=15 的记录，也会被自己的间隙锁挡住吗？实际上 A 可以插入自己间隙锁保护范围内的记录？答案是不行的，InnoDB 中间隙锁不排斥同一事务的插入，但同一个间隙区域内如果有记录插入，还需检查是否和记录锁冲突。
这种复杂的锁交互经常导致开发人员完全摸不着头脑。我见过的一个案例是：两个并发事务往同一张表里插入记录，插入前都会先执行一条 SELECT ... WHERE key = ? FOR UPDATE 查询确认记录是否已存在，结果这个查询产生的间隙锁互相冲突，导致两个事务都卡住，最终被死锁检测机制触发。解决方法是：确认记录是否存在时，用普通 SELECT，或者把事务内的该步骤放在最前面并快速提交。
5.3 死锁检测与死锁回滚机制
InnoDB 默认开启死锁检测，机制是维护一个事务等待图，当检测到图中存在环时，就选择回滚一个代价最小的事务。代价的计算依据是事务执行的更新行数、锁数量等指标。
可以通过以下参数控制死锁相关行为：
innodb_deadlock_detect：是否开启死锁检测，默认ON。高并发场景下，死锁检测本身也有性能开销，某些极端场景可以关闭，依赖innodb_lock_wait_timeout兜底，但这属于危险操作，没有足够的调优经验不建议碰。innodb_lock_wait_timeout：等待锁的超时时间，默认 50 秒。超过这个时间还没有拿到锁，语句会报Lock wait timeout exceeded错误。
死锁错误返回码是 1213（ER_LOCK_DEADLOCK），应用层要做的是：捕获错误，稍作延迟后重试整个事务。这是目前最通用的解决方案。
5.4 预防死锁的实战建议
死锁无法完全消除，但可以大幅降低发生概率。以下几招是我在实际项目中反复验证有效的：
- 固定访问顺序：多个事务访问多张表或多个记录时，都按相同的顺序操作，能避免循环等待
- 减小事务范围：尽量少的事务步骤、尽量短的执行时间，减少持有锁的时间窗口
- 用索引优化查询：减少锁覆盖的记录数，降低冲突面
- 避免大范围锁：
UPDATE ... WHERE条件尽量精确，避免无索引导致锁全表 - 调整隔离级别：如果业务能接受，降为
READ COMMITTED可以减少间隙锁引发的死锁
还有一个小技巧：对于一些热点记录的更新，可以在应用层做“串行化”，比如对同一个用户 ID 的更新通过消息队列或分布式锁排队执行，从源头避免并发写冲突。
6. 锁与业务：监控、排查与优化落地
6.1 快速定位锁等待和阻塞源头
线上遇到锁问题时，第一件事不是去看理论，而是快速定位“谁锁了谁”。我的排查顺序是：
第一步，SHOW PROCESSLIST 查看当前所有会话的状态，找到状态为 Waiting for table metadata lock、Waiting for lock、Lock wait timeout exceeded 的会话。
第二步，查询 information_schema.innodb_trx，找到当前所有未结束的事务，重点看 trx_started 时间，找出长事务：
sql复制SELECT * FROM information_schema.innodb_trx\G
第三步，查询 information_schema.innodb_lock_waits，找到锁等待关系：
sql复制SELECT * FROM information_schema.innodb_lock_waits\G
这个表会告诉你：哪个事务在等待哪个事务释放锁。拿到结果后，再去 SHOW PROCESSLIST 里确认等待者和持有者，判断持有者事务是否可以安全终止。
第四步，如果无法明确找到持有者，可以查询 performance_schema.metadata_locks 来看 MDL 锁的持有和等待关系（MySQL 5.7 及以上版本）。
6.2 常用锁相关参数速查
InnoDB 锁相关的参数不多，但每个都很关键。我整理了一张速查表：
| 参数名 | 默认值 | 作用 |
|---|---|---|
innodb_lock_wait_timeout |
50 | 事务等待行锁的超时时间（秒），超过报错 |
innodb_deadlock_detect |
ON | 是否开启死锁检测 |
innodb_autocommit |
ON | 是否开启自动提交，关闭后需要手动提交事务 |
transaction-isolation |
REPEATABLE-READ | 事务隔离级别 |
innodb_status_output_locks |
OFF | 是否在 SHOW ENGINE INNODB STATUS 中输出更多锁信息 |
排错时诊断信息最丰富的命令是：
sql复制SHOW ENGINE INNODB STATUS\G
输出内容里有一段 LATEST DETECTED DEADLOCK，记录了最近一次死锁的详细信息，包括参与死锁的两个事务的执行语句、持有的锁、等待的锁、被回滚的事务。这是分析死锁问题的第一手资料。
我在实际工作中踩过的坑是：SHOW ENGINE INNODB STATUS 中的死锁信息只在死锁发生后的短时间内保留，重启或重新开启新的诊断后旧的记录可能被覆盖。所以遇到死锁问题，及时抓取现场很重要。另外，innodb_status_output_locks 开启后可能产生大量日志，确认问题后记得关闭。
6.3 一个更新超时问题的排查过程记录
有次业务方反馈，某核心表的 UPDATE 语句偶尔会出现 20 秒以上的延迟。我接到任务后按以下流程排查：
- 先用
SHOW PROCESSLIST查看所有会话，发现有一个会话的状态是Waiting for lock，等待时间已经超过 10 秒 - 结合
information_schema.innodb_trx查看，确认等待者事务是一个UPDATE语句，当前要更新的记录 id=100 - 再查
innodb_lock_waits，发现锁持有者是一个已经运行了 5 分钟的事务，该事务先执行过一条SELECT ... FOR UPDATE - 查
SHOW ENGINE INNODB STATUS的死锁日志，确认是间隙锁冲突
最后定位到问题根源：业务代码里有个批量处理逻辑，每次启动时先用 SELECT ... FOR UPDATE 把一批记录锁住，然后逐条处理，处理完成后统一提交。但处理逻辑本身耗时较长，加上其中还嵌套了外部接口调用，导致事务长时间持有行锁。凌晨定时任务启动时，恰好和正常业务的更新语句产生锁竞争。
解决方式是把批量处理逻辑改成分批提交，每处理完一批就提交一次，同时把 SELECT ... FOR UPDATE 改为普通查询，配合乐观锁版本号字段来控制并发更新。这个方案上线后，锁等待问题彻底消失。
6.4 线上锁问题的预防性设计
与其等锁问题爆雷再去排查，不如在设计阶段就把锁风险控制住。我总结了几条预防性经验：
- 所有事务方法必须短小精悍，事务内禁止调用远程接口、执行耗时操作
- 更新操作必须走索引，
EXPLAIN看执行计划确认 - 批量更新大数据量时，先查主键再分批更新，避免单条 SQL 锁大量记录
- 长事务要有监控告警，超过 5 秒或 10 秒就报警
- 连接池配置合理，避免连接空闲但事务未提交
7. 锁排查实用工具与经验速查
7.1 一套拿来即用的排查 SQL
下面这组 SQL 是我在生产环境排查锁问题时几乎每次都会用的，直接复制就能跑。
查看所有正在执行的事务：
sql复制SELECT * FROM information_schema.innodb_trx\G
查看锁等待关系：
sql复制SELECT
r.trx_id AS waiting_trx_id,
r.trx_mysql_thread_id AS waiting_thread,
b.trx_id AS blocking_trx_id,
b.trx_mysql_thread_id AS blocking_thread,
b.trx_query AS blocking_query
FROM information_schema.innodb_lock_waits w
JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id
JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id;
查看当前所有会话：
sql复制SHOW FULL PROCESSLIST;
终止指定会话：
sql复制KILL <thread_id>;
这套查询足够应对 90% 的锁问题。
7.2 从 SHOW ENGINE INNODB STATUS 中读取关键信息
很多开发者看到 SHOW ENGINE INNODB STATUS 输出很长就直接放弃，其实只需要关注两个段落：TRANSACTIONS 和 LATEST DETECTED DEADLOCK。
在 TRANSACTIONS 段落里，能找到事务列表及其持有的锁信息。LATEST DETECTED DEADLOCK 段落会打印死锁发生时两个事务的完整上下文，包括：
- 每个事务执行过的 SQL
- 事务持有的锁类型和锁住的记录
- 事务等待的锁
有一次死锁日志里明确显示两个事务都锁住了同一索引页的 supremum 记录（索引中最大的虚拟记录），这就是典型的插入冲突导致的死锁。结合业务代码里 INSERT ... ON DUPLICATE KEY UPDATE 的并发频率，最终判断是唯一键检查时的插入意向锁互相竞争，通过调整并发度和重试机制解决。
7.3 锁相关的几点经验之谈
文章最后说点我在真实环境里积累的体会。
第一，别把锁机制只当面试知识点。生产环境里，锁导致的故障往往藏得很深，表面现象是超时、卡顿、吞吐量下降，不深入排查根本看不见是锁在捣乱。掌握锁机制，不只是为了回答“间隙锁和临键锁的区别”，更是为了在系统出问题时能快速判断“是不是锁的问题、谁锁了谁、怎么解除”。
第二，优化锁性能之前，先确认业务是否真的在高并发下运行。很多中小项目的瓶颈根本不在锁上，而是慢查询、缺索引、连接池过小。过早地调隔离级别或死锁检测参数，反而可能引入新的风险。
第三，每次解决完锁问题，我建议把死锁日志、排查过程、解决方案沉淀到团队文档里。锁问题非常有“场景性”，一个团队遇到过的典型问题，大概率会换个姿势再出现一次。
锁机制是 MySQL 里最值得花时间啃透的模块之一，它联系着索引、事务、隔离级别、并发控制、性能调优这些核心知识。把这条线理清楚，数据库基础就算是真正扎实了。