mysql innodb从不主动升级行锁为表锁，所谓“升级”实为优化器放弃索引导致全表扫描逐行加x锁，或rr级别下临键锁爆炸式扩张等效锁表；根本原因是where条件未走索引、隐式类型转换、函数包裹索引列或统计信息过旧。
MySQL InnoDB 从不主动“升级”行锁为表锁——所谓升级，其实是优化器放弃索引后被迫全表扫描、或临键锁爆炸式扩张导致的逻辑等效现象。它不是锁类型切换，而是锁范围失控的后果。
WHERE条件没走索引时，InnoDB会逐行加X锁
行锁本质是加在索引记录上的，没索引就只能扫聚簇索引（即整张表）。此时每条被扫描的主键记录都会被加上排他锁（X Lock），在可重复读（RR）隔离级别下还会附带 Gap Lock 和 Next-Key Lock。
-
EXPLAIN显示type为ALL或index，且key为NULL，基本可确认没走索引 - 典型失效写法：
WHERE SUBSTRING(name, 1, 2) = 'Li'、WHERE user_id = '123'（user_id是INT）、WHERE status IN (1,2) OR type = 'A'（非组合索引+OR） - 效果上等同于锁表：其他事务对任意行的
UPDATE/DELETE都会被阻塞
RR隔离级别下间隙锁叠加引发锁范围失控
RR 级别默认用 Next-Key Lock（Record Lock + Gap Lock）防幻读。范围查询一旦涉及大量间隙，锁结构内存占用（heap size）可能突破 1MB，InnoDB 会倾向简化处理，表现为对整个索引段加锁，监控上接近表锁行为。
- 例如：
SELECT * FROM orders WHERE amount BETWEEN 100 AND 1000 FOR UPDATE，若该范围覆盖数百个间隙，INNODB_TRX.TRX_ROWS_LOCKED可能高达数万 -
SHOW ENGINE INNODB STATUS\G中若看到lock struct(s), heap size 1245678（超 1MB），就是强信号 - 对比：RC 级别下同一条语句只加 Record Lock，不锁间隙，锁范围小得多
如何判断是否发生了隐式锁升级？盯住三个指标
锁升级不报错、不记日志（除非开启 innodb_status_output_locks），必须靠交叉验证：
- 查
information_schema.INNODB_TRX：若TRX_ROWS_LOCKED远高于业务预期（比如只改 1 行却显示锁了 5 万行），说明锁范围已失控 - 看
SHOW ENGINE INNODB STATUS\G的TRANSACTIONS段：heap size超过 1MB 是内存压力触发简化策略的关键依据 - 执行
SHOW GLOBAL STATUS LIKE 'table_locks%'：若table_locks_waited显著上升，而table_locks_immediate下降，说明有非 MyISAM 引擎语句正遭遇表级阻塞逻辑
真正难排查的不是“有没有锁升级”，而是“为什么明明建了索引，还是没走”。隐式类型转换、函数包装、统计信息陈旧、或者 OR 条件破坏索引合并，都可能让执行计划悄然退化——这些细节往往比锁机制本身更决定最终行为。
