MySQL 8.0 中不存在可被观测的“隐式锁转化过程”，隐式锁仅为未提交记录的轻量级 trx_id 标记，不生成真实锁结构；仅当其他事务执行当前读并访问该记录时，才触发显式加锁并出现在 data_locks 和 SHOW ENGINE INNODB STATUS 的 TRANSACTIONS 段中。
SHOW ENGINE INNODB STATUS 里根本看不到“隐式锁转化”过程
MySQL 8.0 中不存在可被观测的“隐式锁转化过程”。所谓“隐式锁”不是一种真实存在的锁状态，而是 InnoDB 在插入或更新时对未提交记录的一种轻量级标记（仅靠 trx_id 字段），它不注册锁结构、不写入 performance_schema.data_locks、也不出现在任何锁视图中。你看到的永远是“冲突发生后首次加锁”的结果，不是“转化中”的中间态。
真正能观察到的，是隐式锁被触发后的显式锁登记
当另一个事务执行当前读（如 SELECT ... FOR UPDATE 或 UPDATE）并访问到一个由未提交事务插入/修改的行时，InnoDB 才会为该行分配真实锁结构，并立刻出现在以下位置：
-
performance_schema.data_locks中新增一条LOCK_TYPE = 'RECORD'、LOCK_MODE含X的记录，LOCK_TRX_ID指向原事务 ID -
SHOW ENGINE INNODB STATUS\G的TRANSACTIONS段中，出现类似lock_mode X locks rec but not gap insert intention waiting的等待描述——这是隐式锁机制被触发的最典型信号 - 若原事务已持有间隙锁（如因范围查询），新事务插入时可能升级为
X locks gap before rec，此时两个事务在data_locks中会显示交叉的NEXT-KEY锁
为什么 EXPLAIN 和 data_locks 查不到“正在隐式”的锁
因为它们压根没创建锁对象：
-
EXPLAIN只反映执行计划路径，不体现锁行为；即使某条INSERT触发了隐式锁机制，EXPLAIN也只会显示type: ALL或range，和锁无关 -
performance_schema.data_locks是锁结构快照表，只记录已分配内存的锁；隐式锁阶段无锁结构，查出来就是空的 - 试图用
SELECT * FROM performance_schema.data_locks WHERE LOCK_TRX_ID = 'xxx'去抓“隐式中”的锁，注定失败——那个事务 ID 此时只存于聚簇索引记录头，还没生成锁对象
排查时最容易忽略的关键点
隐式锁是否被触发，完全取决于**另一事务是否执行了当前读 + 是否命中了带活跃 trx_id 的记录**。这意味着：
- 如果业务用的是
autocommit=1，单条INSERT瞬间提交，trx_id马上清空，后续任何查询都看不到痕迹 - 普通
SELECT不触发检测，哪怕它读到了刚插入但未提交的行（在 RC 隔离级别下可能看到，在 RR 下会被 MVCC 屏蔽） - 二级索引上的隐式锁检测依赖
PAGE_MAX_TRX_ID，比聚簇索引更难定位；若怀疑问题出在二级索引，必须结合SHOW ENGINE INNODB STATUS中的INSERT BUFFER AND ADAPTIVE HASH INDEX段看页面状态
