用锁监控信息解释多个插入事务在同一索引间隙中的等待与兼容关系

多个事务向同一索引间隙插入不同位置的记录，插入意向锁不必彼此阻塞；但它们都可能被另一个事务持有的间隙保护挡住。判断时应把“请求锁”和“实际阻塞锁”关联起来，而不是看到两个 INSERT 都在等待，就认定它们互相冲突。MySQL 8.4 可通过 performance_schema.data_lock_waits 与 data_locks 阅读这种关系。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/innodb-locking.html

先分清同一间隙与同一插入位置

我会先问两个具体问题：两个请求是否真的落在同一个索引间隙，阻塞方是否真的是另一个插入事务。前者描述位置，后者描述依赖关系，不能用其中一个替代另一个。这是本文建议的分析习惯，不是某次线上事故的实录。

插入意向锁用于表达插入位置的需求。假设索引只有 30 和 60，事务 B 想插入 41，事务 C 想插入 49，两者属于同一间隙，但位置不同。在没有其他冲突的简单场景中，它们不因共享这一个间隙就互相排队。若事务 A 已对该间隙建立禁止插入的保护，两者则可能共同等待 A。

这里不把兼容性扩展成“所有 INSERT 都能并行”。相同唯一键、其他索引和其他约束，都可能带来额外冲突。示例特意只保留一个显式整数主键，避免将不同机制混在一起；表级 IX 也不能直接等同于插入意向锁。

最小 SQL 配方：把等待双方连起来

最小配方是以等待关系为入口，将请求锁 ID 和阻塞锁 ID 分别连到锁对象。ENGINE 与 ENGINE_LOCK_ID 组合用于匹配，不解析锁 ID 内部字符串。下面的查询只读取监控数据；运行时应先选中目标库，并具备相应监控表的读取权限。

-- 在目标库中查询当前示例表的等待关系，分别保留请求方和阻塞方。
SELECT
    w.REQUESTING_ENGINE_TRANSACTION_ID AS waiting_trx,
    w.BLOCKING_ENGINE_TRANSACTION_ID AS blocking_trx,
    r.INDEX_NAME AS requested_index,
    r.LOCK_TYPE AS requested_type,
    r.LOCK_MODE AS requested_mode,
    r.LOCK_STATUS AS requested_status,
    r.LOCK_DATA AS requested_data,
    b.INDEX_NAME AS blocking_index,
    b.LOCK_MODE AS blocking_mode,
    b.LOCK_STATUS AS blocking_status,
    b.LOCK_DATA AS blocking_data
FROM performance_schema.data_lock_waits AS w
JOIN performance_schema.data_locks AS r
  ON r.ENGINE = w.ENGINE
 AND r.ENGINE_LOCK_ID = w.REQUESTING_ENGINE_LOCK_ID
JOIN performance_schema.data_locks AS b
  ON b.ENGINE = w.ENGINE
 AND b.ENGINE_LOCK_ID = w.BLOCKING_ENGINE_LOCK_ID
WHERE r.OBJECT_SCHEMA = DATABASE()
  AND r.OBJECT_NAME = 'insert_gap_sample'
  AND w.ENGINE = 'INNODB';

waiting_trx 与 blocking_trx 是解释依赖的核心。如果 B、C 的等待关系都指向 A，那是共同阻塞者；只有监控关系实际指向彼此，才有理由进一步分析它们之间的冲突。一个请求也可能对应多个阻塞对象，不要把结果强行压成一条一对一关系。

查询保留两侧索引、模式和状态，是为了先确定对象，再解释锁的含义。只筛选一个看起来像插入意向的模式字符串，可能丢失阻塞方的信息。保留原始字段比把模式简化为“写锁”更有助于辨认范围保护和记录保护。

用三会话场景理解共同阻塞者

下面给出独立演示库中的会话配方，仅用于说明操作关系。本文未启动数据库、未执行这些 SQL，也没有生成监控截图或假造事务 ID。准备表后，A 持有范围锁，再让 B 与 C 分别尝试插入；监控查询应在另一个能够继续发出查询的连接里使用。

-- 仅在独立演示库准备；没有自增列和其他唯一索引。
CREATE TABLE insert_gap_sample (
    id INT NOT NULL PRIMARY KEY
) ENGINE=InnoDB;
INSERT INTO insert_gap_sample (id) VALUES (30), (60);

-- 会话A：保持事务未结束，建立范围锁定场景。
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;
SELECT id FROM insert_gap_sample
WHERE id > 30 AND id 

-- 会话B：在A保持范围保护时尝试插入。
START TRANSACTION;
INSERT INTO insert_gap_sample (id) VALUES (41);
-- INSERT 返回且观察完成后结束B的事务。
-- ROLLBACK;

-- 会话C：使用同一间隙内另一个未占用主键。
START TRANSACTION;
INSERT INTO insert_gap_sample (id) VALUES (49);
-- INSERT 返回且观察完成后结束C的事务。
-- ROLLBACK;

本场景明确把 A 设为 REPEATABLE READ，并使用主键范围锁定读。按该配置的锁定语义，A 的范围保护会涉及目标插入位置；B 和 C 的位置不同，并不意味着可以越过 A 的保护。监控中若观察到它们都依赖 A，这与两个插入意向本身可以兼容并不矛盾。

A 结束后，B、C 仍各自拥有事务生命周期，不能把 A 的回滚当作所有连接都已经清理。等各自 INSERT 返回或错误得到处理，再在对应连接结束事务。若发生超时或死锁，应先处理该连接的错误与事务状态，再安排后续操作，避免把预定执行顺序当成实际执行结果。

监控字段怎样避免误判

间隙相关锁的监控对象可能关联间隙后面的索引记录，因此不能看到 LOCK_DATA 中的 60，就断定事务正在插入 60。InnoDB 状态说明中的 insert intention waiting 字样用于表达请求插入意向时正在等待；需要结合索引位置和阻塞对象阅读，而不是把几个词拆成互不相关的结论。

监控是当前状态。锁可能在查询之间被授予或释放，关联查询没有结果不等于历史上从未发生阻塞；顺利完成的插入意向也未必长期留在等待表中。应把观察时间、目标库表、两侧事务与相关 SQL 一起保存，避免只截取一行模式字段反复推断。

变体、处置与常见问题

处置时我更倾向于先确认阻塞事务的业务用途、持锁原因和事务边界，再决定如何缩短持锁时间。不要仅因两个插入在同一间隙，就急着拆表或改键。也不要为了让演示不再等待，直接把生产隔离级别或锁定读删掉；这可能改变应用原本依赖的并发语义。

两个插入都等着，算死锁吗？不一定。共同等待 A 没有自动构成循环依赖，需由实际等待关系判断。

同一间隙为什么不能只看一个锁模式？因为位置与阻塞对象都重要，同样的模式名称不足以描述完整依赖。

两个事务插入同一个主键，也能套这个结论吗？不能。不同位置、无其他冲突是这里的限定条件；相同唯一键需要另外分析唯一性检查与记录锁。

最有用的诊断产物是一组能互相对应的请求锁、阻塞锁和事务信息。先解释真实依赖，再选择事务层面的处理方式，能避免把共同等待误读成插入意向彼此不兼容。

参考：InnoDB 锁定说明；data_locks 字段；data_lock_waits 关联关系。