锁升级实为索引缺失导致的全表扫描加锁，并非InnoDB主动行为；SHOW ENGINE INNODB STATUS显示TABLE LOCK、mode IX且无locks rec but not gap，结合EXPLAIN type为ALL/index且key为NULL，即可确认未走索引。
锁升级不是InnoDB的主动行为，而是索引缺失或失效导致行锁被迫扩大范围——本质是没走索引，InnoDB只能全表扫描并加锁，看起来像“升级”，实际是退化。
为什么SHOW ENGINE INNODB STATUS里会显示表级等待？
当死锁日志中出现TABLE LOCK、mode IX（意向排他锁）或type: TABLE，且lock_mode X locks rec but not gap完全没出现时，基本可断定：SQL没命中任何索引，触发了全表扫描+全表加锁。这不是真正的“锁升级”，而是InnoDB在无索引情况下对整张表施加的最保守保护。
- 检查
EXPLAIN输出：type为ALL或index，且key为NULL，就是铁证 - 注意WHERE条件字段是否被函数包裹（如
WHERE DATE(created_at) = '2026-07-01'），这会让索引失效 - 联合索引中，如果只用了后缀列（如索引
(a,b,c)，但查询只用WHERE c = 1），同样不走索引
SELECT ... FOR UPDATE没走索引时怎么快速定位？
这类语句最容易暴露锁范围问题——它本应只锁几行，却锁了成百上千行甚至整表。排查必须从执行计划切入：
- 在相同WHERE条件下执行
EXPLAIN FORMAT=TRADITIONAL SELECT ... FROM t WHERE ...，对比rows和filtered值；若rows接近表总行数，说明扫描范围过大 - 用
INFORMATION_SCHEMA.STATISTICS确认该字段是否有可用索引：SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = 'db' AND TABLE_NAME = 't' AND COLUMN_NAME = 'xxx'; - 临时强制走某个索引测试：
SELECT ... FROM t FORCE INDEX (idx_name) WHERE ... FOR UPDATE;，看是否能缩小rows
补索引后为什么死锁还在？
补索引只是第一步，但可能因以下原因仍无效：
- 索引类型不匹配：比如WHERE用
status VARCHAR(20)，但索引建在status(10)上，前缀索引无法支撑等值判断 - 字符集/排序规则不一致：应用传入的字符串与字段定义的
collation不同（如utf8mb4_0900_as_csvsutf8mb4_general_ci），导致隐式转换、索引失效 - 事务内先查后更新，但查用的是非唯一索引，而更新用的是主键——查的时候已加间隙锁，更新时又试图加记录锁，形成冲突
- MySQL统计信息过期：
ANALYZE TABLE t;强制刷新后，执行计划才真正反映新索引效果
间隙锁引发的伪“锁升级”怎么区分？
真正麻烦的是REPEATABLE READ下因间隙锁导致的锁范围膨胀——它不会显示TABLE LOCK，但lock_mode X locks gap before rec说明锁住了索引间隙，可能覆盖大量不存在的行。
- 范围查询（
WHERE id > 100）、LIKE 'abc%'、非唯一索引等值查询（WHERE status = 'pending'），都可能触发间隙锁 - 唯一索引+等值查询（
WHERE id = 123）不会加间隙锁，只加记录锁；这是最安全的模式 - 若业务允许，临时切换隔离级别：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;，可彻底关闭间隙锁（但需评估幻读风险）
真正难处理的不是锁本身，而是同一段SQL在不同数据分布、不同统计信息、不同隔离级别下，锁行为可能完全不同——别只盯着日志里的“锁类型”，得把EXPLAIN、索引定义、字段类型、字符集、隔离级别全串起来看。
