InnoDB行锁锁的是索引记录而非数据行：无索引时退化为表锁；主键查询锁聚簇索引记录，二级索引查询可能锁二级索引及对应聚簇索引记录，并在RR级别触发gap lock或next-key lock防幻读。
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 后，另一个事务插入 a = 15 会被阻塞，哪怕表里原本没有 a = 15 的记录——这就是间隙锁生效了。
- 间隙锁锁定的是索引值之间的“空隙”，例如索引有 [1,5,9]，则间隙为 (-∞,1)、(1,5)、(5,9)、(9,+∞)
- next-key lock = 间隙锁 + 记录锁，覆盖“左开右闭”区间，如 (5,9]，用于范围条件
- 唯一索引的等值查询（含主键）不会加间隙锁，只加 record lock；但范围查询（
>,,BETWEEN）会 - 显式关闭间隙锁：设置
innodb_locks_unsafe_for_binlog = ON（已弃用），或改用READ COMMITTED隔离级别
锁升级不存在，但锁数量爆炸很常见
InnoDB 不支持锁升级（lock escalation），不会把大量行锁合并成一个表锁。但它可能因查询条件不精确，导致一次性锁住成百上千个索引项——尤其是 ORDER BY ... LIMIT 配合 FOR UPDATE 时，优化器可能无法精确估算扫描范围，从而锁住远超预期的记录。
Modoer 是一款以本地分享，多功能的点评网站管理系统。采用 PHP+MYSQL 开发设计，开放全部源代码。因具有非凡的访问速度和卓越的负载能力而深受国内外朋友的喜爱，不局限于商铺类点评，真正实现了多类型的点评，可以让您的网站点评任何事与物，同时增加产品模块，也更好的网站产品在网站上展示。Modoer点评系统 2.5 Build 20110710更新列表1.同步 旗舰版系统框架2.增加 限制图片
一个真实案例：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 等指标交叉验证。
