隐式锁不是锁结构，而是记录中trx_id字段指向活跃事务的标记；所谓“转化”实为其他事务执行当前读时，检测到该trx_id并主动为原事务创建显式锁结构。
MySQL 不会“自动转化”隐式锁为显式锁——这是个关键误解。所谓“转化”，其实是另一个事务在读/写时，检测到目标记录上有隐式锁（即存在未提交事务的 trx_id），于是主动为其创建一个显式锁结构。
隐式锁根本不是锁结构，只是 trx_id 标记
隐式锁没有对应的 lock_t 结构，查 performance_schema.data_locks 看不到它。它只存在于聚簇索引或二级索引记录的 DB_TRX_ID 字段里：只要该字段值指向一个活跃事务（未提交），就表示这条记录被该事务“隐式持有”。
常见误判场景：
- 执行
INSERT INTO t VALUES (100, 'x')后立刻查data_locks→ 查不到任何锁，但此时记录已有隐式锁 - 执行
UPDATE t SET x=1 WHERE id = 100（id 是主键）→ 若无并发冲突，InnoDB 可能全程不建锁结构，只改DB_TRX_ID -
SELECT * FROM t WHERE id = 100（纯读）→ 默认不触发任何锁，无论是否开启事务
所谓“转化”发生在其他事务尝试当前读时
当事务 B 对事务 A 插入/更新但尚未提交的记录执行当前读（如 SELECT ... LOCK IN SHARE MODE 或 SELECT ... FOR UPDATE），InnoDB 会走以下路径：
- 读取目标记录的
DB_TRX_ID - 检查该 trx_id 是否对应一个活跃事务（
trx_is_active()） - 若活跃且该事务尚未在该记录上加显式锁 → 调用
lock_rec_convert_impl_to_expl()创建一个新锁（如LOCK_X | LOCK_REC_NOT_GAP） - 这个新锁归事务 B 所有，但作用对象是事务 A 的那条记录
注意：这个动作不是“事务 A 把锁升级了”，而是“事务 B 帮事务 A 补上了锁结构”。事务 A 自己仍无显式锁。
哪些操作会触发隐式锁检测与转化？
只有满足“当前读 + 记录存在 + 隐式持有者活跃”三要素时才触发。典型组合：
- 事务 A：
INSERT INTO t VALUES (100, 'x');（未提交） - 事务 B：
SELECT * FROM t WHERE id = 100 LOCK IN SHARE MODE;→ 触发转化，B 获得 S 锁，A 的记录被显式标记 - 事务 A：
UPDATE t SET name='y' WHERE id = 100;（id 是唯一索引） - 事务 B：
UPDATE t SET name='z' WHERE id = 100;→ 冲突检测时触发转化，B 创建 X 锁并进入等待
不会触发的情况：
- 事务 B 执行
SELECT * FROM t WHERE id = 100;（无锁读）→ 完全不检测 - 事务 B 执行
SELECT * FROM t WHERE id > 100 FOR UPDATE;（范围扫描）→ 只对扫描到的已存在记录做检测，不涉及 A 插入的 100 - 事务 A 已提交 →
DB_TRX_ID不再指向活跃事务，B 直接读取，无转化
为什么你查不到“转化过程”，只能看到结果？
因为整个检测和建锁动作对用户完全透明，且发生在内核 mutex 保护下，毫秒级完成。你能观察到的只有转化后的结果：
- 事务 B 执行完
SELECT ... FOR UPDATE后，performance_schema.data_locks中突然多出一条LOCK_DATA指向该记录的 X 锁 - 锁的
OWNER_THREAD_ID是事务 B 的线程 ID，不是事务 A 的 - 事务 A 依然查不到自己有任何锁记录 —— 它从头到尾就没拥有过显式锁
真正容易被忽略的是：这个“转化”不是协作行为，而是冲突驱动的防御机制。它不保证原子性、不提供语义承诺，只解决“我读你刚写的未提交数据”这一瞬间的可见性与一致性问题。
