InnoDB 的行锁到底锁的是“记录”还是“索引”
InnoDB 行级锁不是直接锁数据行，而是锁
索引记录（index record）。这意味着：没有索引的表（即堆表）无法使用行锁，只能退化为表锁；即使有索引，如果
WHERE条件未命中索引（如全表扫描），也会锁住所有扫描过的索引项——包括间隙（gap）甚至整个范围。
常见错误现象：
UPDATE t SET x=1 WHERE id=100;却导致其他事务更新
id=101被阻塞——大概率是因为
id列没建索引，或该查询走的是二级索引+回表路径，实际锁住了二级索引中的记录及对应聚簇索引记录。 主键查询（
WHERE id = ?）→ 锁聚簇索引上的单条记录（record lock） 唯一二级索引等值查询 → 先锁二级索引记录，再锁对应聚簇索引记录 非唯一二级索引查询 → 可能触发
next-key lock（记录锁 + 间隙锁），范围更大
SELECT ... FOR UPDATE或
UPDATE/DELETE在可重复读（RR）下默认用 next-key lock 防幻读
间隙锁（Gap Lock）和临键锁（Next-Key Lock）怎么触发
间隙锁只在事务隔离级别为
REPEATABLE READ时启用，且仅对已存在的索引间隙加锁，不锁记录本身。它防止其他事务在间隙中插入新记录，是 InnoDB 实现“可重复读”不出现幻读的关键机制。
典型误判场景：执行
SELECT * FROM t WHERE a > 10 AND a 后，另一个事务插入 <code>a = 15会被阻塞，哪怕表里原本没有
a = 15的记录——这就是间隙锁生效了。 间隙锁锁定的是索引值之间的“空隙”，例如索引有 [1,5,9]，则间隙为 (-∞,1)、(1,5)、(5,9)、(9,+∞) next-key lock = 间隙锁 + 记录锁，覆盖“左开右闭”区间，如 (5,9]，用于范围条件 唯一索引的等值查询（含主键）不会加间隙锁，只加 record lock；但范围查询（
>,
, <code>BETWEEN）会 显式关闭间隙锁：设置
innodb_locks_unsafe_for_binlog = ON（已弃用），或改用
READ COMMITTED隔离级别
锁升级不存在，但锁数量爆炸很常见
InnoDB 不支持锁升级（lock escalation），不会把大量行锁合并成一个表锁。但它可能因查询条件不精确，导致一次性锁住成百上千个索引项——尤其是
ORDER BY ... LIMIT配合
FOR UPDATE时，优化器可能无法精确估算扫描范围，从而锁住远超预期的记录。
一个真实案例：
SELECT * FROM order WHERE status = 'pending' ORDER BY created_at LIMIT 1 FOR UPDATE;，若
status无索引，就会扫描全表并给每条匹配记录加锁；即使有索引，若
created_at未包含在联合索引中，也可能导致排序前先锁大量行。 避免锁扩散：确保
WHERE和
ORDER BY字段被同一联合索引覆盖（如
(status, created_at)） 检查执行计划：
EXPLAIN中
key和
rows字段能反映实际扫描与加锁范围 用
SELECT ... LOCK IN SHARE MODE替代
FOR UPDATE，若业务允许共享访问 监控锁等待：
SELECT * FROM information_schema.INNODB_TRX;+
INNODB_LOCK_WAITS+
INNODB_LOCKS（8.0+ 已移除后者，改用
performance_schema.data_locks）
死锁检测不是靠超时，而是主动图遍历
InnoDB 死锁检测是实时的、基于等待图（wait-for graph）的深度优先搜索，一旦发现环就立即回滚其中一个事务（选
undo log量小的那个），而不是等到
innodb_lock_wait_timeout（默认 50 秒）超时。
所以你看到的
Deadlock found when trying to get lock错误，是 InnoDB 主动干预的结果，不是等待失败。这也意味着：死锁日志（
SHOW ENGINE INNODB STATUS输出）里一定包含至少两个事务的完整加锁/等待链路。 死锁日志中重点关注
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:和
*** (2) HOLDS THE LOCK(S):两段 高频死锁模式：多个事务以不同顺序更新同一组记录（如转账 A→B 和 B→A） 缓解方式：固定 DML 操作顺序（如按主键升序更新）、拆分大事务、减少事务内 SQL 数量 注意：唯一索引冲突插入（
Duplicate entry）也可能引发隐式锁和死锁，尤其在高并发
INSERT ... ON DUPLICATE KEY UPDATE场景
真正难排查的是锁兼容性边缘情况——比如一个事务持有了二级索引的 gap lock，另一个事务尝试在相同间隙插入，却因索引结构分裂导致锁对象变化；这类问题往往需要结合
information_schema.innodb_metrics中的
lock_row_lock_time_avg等指标交叉验证。
