隐式锁并非真正存在，而是事务ID标记；仅当另一事务执行当前读且访问到未提交行时，InnoDB才首次创建显式锁，此前无任何锁结构。
隐式锁根本不会“转换”，它只是被检测到后才真正加锁
MySQL InnoDB 中不存在“隐式锁自动变成显式锁”的过程。所谓“隐式锁”，其实是对一种轻量级状态标记的误称：当事务插入或修改一行时，InnoDB 仅在记录的 trx_id 字段写入当前事务 ID，**此时并未分配任何锁结构，也没有锁对象生成**。你查 performance_schema.data_locks 查不到它，SHOW ENGINE INNODB STATUS 也看不到它——因为它压根没存在过。
只有另一个事务执行「当前读」并访问到该行，且发现其 trx_id 指向一个未提交事务时，InnoDB 才会：
- 立即为原事务创建一个真实的 X 锁（显式锁）
- 同时为自己创建等待中的 S 或 X 锁
这个动作不是“转化”，而是“首次加锁”。之前那行上什么锁都没有，只有个事务 ID 标记。
触发显式锁创建的三个硬性条件缺一不可
不是所有并发访问都会触发这个机制。必须同时满足：
- 执行的是当前读语句：
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE（普通SELECT不触发） - 目标行真实存在（聚簇索引中可定位到，不能是空扫描）
- 该行的
trx_id（主键/唯一索引）或所在页的PAGE_MAX_TRX_ID（二级索引）指向一个活跃未提交事务
例如：INSERT INTO t VALUES (100, 'x') 未提交，事务 B 执行 SELECT * FROM t WHERE id = 100 FOR UPDATE 就会触发；但若 B 执行的是无锁 SELECT * FROM t WHERE id = 100，则完全不检测、不加锁、也不阻塞。
autocommit=1 下隐式锁机制基本失效
单条 DML 在 autocommit=1 模式下会立即提交，事务生命周期极短，trx_id 写入后很快被清除。其他事务几乎来不及检测到这个“窗口”，也就无法触发后续的显式锁创建。
这意味着：
- 你在应用里用 ORM 默认开启 autocommit，又指望靠 INSERT 后的隐式锁保护后续逻辑——大概率失败
- 想让隐式锁机制起作用，必须显式开启事务：
BEGIN+ 多条语句 +COMMIT -
innodb_locks_unsafe_for_binlog=OFF（默认）会影响部分场景下的锁行为，但不改变隐式锁的本质
从 SHOW ENGINE INNODB STATUS 中识别“已触发”的痕迹
SHOW ENGINE INNODB STATUS 不显示隐式锁本身，但能反映它被触发后的结果。重点看 TRANSACTIONS 部分的锁等待链：
- 出现
lock_mode X locks rec but not gap insert intention waiting是典型信号：插入意向锁因冲突升级为记录锁 -
Trx has been waiting X sec for this lock后紧跟着被阻塞的锁类型变化，说明隐式状态已被打破 - 如果没有任何并发冲突，INSERT 即使走隐式锁路径，STATUS 中也不会留下任何痕迹——它就像没发生过一样
真正容易被忽略的点在于：你看到的永远是“已经加了锁”的结果，而不是“正在转化”的中间态。InnoDB 的设计哲学是“不加锁，直到不得不加”，而这个“不得不”，永远由另一个事务的当前读行为来决定。
