InnoDB 的行锁、记录锁、间隙锁和 next-key lock 共同决定写并发行为。理解它们必须结合索引和隔离级别，而不能只看 SQL 表面条件。

1. 学习定位

维度	内容
难度层级	锁机制深入
核心目标	先会用，再理解机制，最后能做工程取舍和故障分析
学习方法	带着业务场景看命令、SQL、数据结构、日志和运行时指标

2. 核心地图

InnoDB行锁与间隙锁
├─ Record Lock
├─ Gap Lock
├─ Next-Key Lock
├─ Insert Intention Lock
├─ 唯一索引
├─ 范围查询
└─ 当前读

3. 小章节深度讲解

下面把核心地图中的每个点拆开讲。每个小节都同时面向开发和运维：开发侧关注怎么设计、怎么写代码、怎么避免错误；运维侧关注怎么监控、怎么定位、怎么恢复。

3.1. Record Lock

是什么

Record Lock 属于 MySQL 并发控制。锁不是简单阻塞工具，而是数据库在多事务并发下保护一致性、范围约束和表结构安全的机制。

开发人员怎么用

开发人员要让更新条件命中索引，统一资源访问顺序，并把重试设计成幂等。涉及状态、库存、余额的写入，要用条件更新缩小锁范围。

运维人员怎么看

运维人员要从阻塞链分析：持锁事务、等待事务、锁类型、索引路径、事务年龄和 SQL 来源。必要时结合 Performance Schema 与 InnoDB status。

常见风险

常见风险是无索引更新或长事务遇到 DDL，行锁、间隙锁和 MDL 叠在一起，最后表现为整张表像被冻住。

3.2. Gap Lock

是什么

Gap Lock 属于 MySQL 并发控制。锁不是简单阻塞工具，而是数据库在多事务并发下保护一致性、范围约束和表结构安全的机制。

开发人员怎么用

开发人员要让更新条件命中索引，统一资源访问顺序，并把重试设计成幂等。涉及状态、库存、余额的写入，要用条件更新缩小锁范围。

运维人员怎么看

运维人员要从阻塞链分析：持锁事务、等待事务、锁类型、索引路径、事务年龄和 SQL 来源。必要时结合 Performance Schema 与 InnoDB status。

常见风险

常见风险是无索引更新或长事务遇到 DDL，行锁、间隙锁和 MDL 叠在一起，最后表现为整张表像被冻住。

3.3. Next-Key Lock

是什么

Next-Key Lock 属于 MySQL 并发控制。锁不是简单阻塞工具，而是数据库在多事务并发下保护一致性、范围约束和表结构安全的机制。

开发人员怎么用

开发人员要让更新条件命中索引，统一资源访问顺序，并把重试设计成幂等。涉及状态、库存、余额的写入，要用条件更新缩小锁范围。

运维人员怎么看

运维人员要从阻塞链分析：持锁事务、等待事务、锁类型、索引路径、事务年龄和 SQL 来源。必要时结合 Performance Schema 与 InnoDB status。

常见风险

常见风险是无索引更新或长事务遇到 DDL，行锁、间隙锁和 MDL 叠在一起，最后表现为整张表像被冻住。

3.4. Insert Intention Lock

是什么

Insert Intention Lock 属于 MySQL 并发控制。锁不是简单阻塞工具，而是数据库在多事务并发下保护一致性、范围约束和表结构安全的机制。

开发人员怎么用

开发人员要让更新条件命中索引，统一资源访问顺序，并把重试设计成幂等。涉及状态、库存、余额的写入，要用条件更新缩小锁范围。

运维人员怎么看

运维人员要从阻塞链分析：持锁事务、等待事务、锁类型、索引路径、事务年龄和 SQL 来源。必要时结合 Performance Schema 与 InnoDB status。

常见风险

常见风险是无索引更新或长事务遇到 DDL，行锁、间隙锁和 MDL 叠在一起，最后表现为整张表像被冻住。

3.5. 唯一索引

是什么

唯一索引 影响 MySQL 的物理访问路径。InnoDB 数据和索引以页为单位组织，主键索引保存整行，二级索引保存主键并可能触发回表。

开发人员怎么用

开发人员要从查询模式设计索引：等值、范围、排序、分组和返回字段要一起考虑。主键要短、稳定、尽量有序，联合索引要遵循最左前缀和选择性原则。

运维人员怎么看

运维人员要看执行计划、索引大小、Buffer Pool 命中、写入延迟和未使用索引。索引治理既包括新增，也包括合并和下线。

常见风险

常见风险是给每个字段都建索引，读查询短期改善，写入、空间、缓存和优化器选择长期恶化。

3.6. 范围查询

是什么

范围查询会按照优化器选择的索引区间访问数据。在可重复读隔离级别下，当前读为了防止幻读，可能对扫描到的记录和记录之间的间隙加 next-key lock 或 gap lock；锁住的范围取决于索引和边界条件。

开发人员怎么用

开发人员要让范围条件尽量命中高选择性索引，并控制区间大小。批量更新和删除要分段执行，避免开放区间；多个事务处理同一范围时要保持一致顺序，降低死锁概率。

运维人员怎么看

运维人员要结合 EXPLAIN、performance_schema.data_locks、锁等待日志和实际 SQL 参数判断锁范围。重点看是否出现全表扫描、低选择性索引、范围过宽和长事务叠加。

常见风险

常见风险是开发以为只处理“几行数据”，但 MySQL 根据索引区间锁住了大片范围，导致插入被间隙锁阻塞，最终表现为业务写入突然排队。

3.7. 当前读

是什么

当前读 关注的是事务版本可见性。InnoDB 通过事务 ID、undo 链和 Read View 判断某个历史版本对当前语句或事务是否可见。

开发人员怎么用

开发人员要区分快照读和当前读。只展示数据可以依赖快照读，读后要更新就要使用当前读、条件更新或唯一约束保护业务不变量。

运维人员怎么看

运维人员要观察长事务、undo 表空间、history list length 和 purge 速度。版本链积压会让查询变慢，也会推迟空间回收。

常见风险

常见风险是长时间打开事务做分页导出或人工审核，导致旧版本长期不能清理，最终拖累整个实例。

3.8. 本篇学习实验

建议准备一个至少百万行级别的测试表，分别观察正常查询、缺失索引、错误索引、长事务、锁等待和慢查询日志。每次实验都记录 SQL、执行计划、耗时、扫描行数和 MySQL 状态变量变化。

开发侧实验重点是理解 SQL 与事务边界，运维侧实验重点是理解指标如何变化。真正掌握本篇内容，应该能从现象反推 SQL、索引、锁、日志或存储引擎问题。

4. 核心机制

• 记录锁锁住已经存在的索引记录，防止其他事务修改或删除。
• 间隙锁锁住索引记录之间的范围，防止其他事务在范围内插入。
• next-key lock 是记录锁和间隙锁的组合，常见于可重复读下的范围当前读。
• 插入意向锁用于多个事务在同一间隙不同位置插入时协调，不等同于普通间隙锁。

5. 工程实践

• 范围更新要确认索引边界，避免锁住比业务预期更大的范围。
• 唯一索引等值命中通常锁定更精确，非唯一索引可能涉及更多记录和间隙。
• 设计并发插入场景时关注唯一约束冲突和插入意向锁等待。
• 用实验复现锁范围，结合 performance_schema.data_locks 分析。

6. 常见坑

• 以为 WHERE id > 10 只锁已有记录，实际还可能锁住范围间隙。
• 非唯一索引重复值很多，导致锁范围比想象大。
• 没有索引导致退化扫描，锁影响面扩大。
• 把读已提交和可重复读的锁行为混为一谈。

7. 专家视角

• 锁范围由访问路径决定，访问路径由索引和优化器决定。
• 专家会通过构造边界数据验证锁行为，而不是只读概念。
• 间隙锁是正确性与并发度的折中，不能简单说好或坏。

8. Tips 快问快答

Q：间隙锁锁的是数据吗？

A：锁的是索引记录之间的范围，用来阻止插入。

Q：唯一索引一定没有间隙锁吗？

A：唯一等值命中通常更精确，但范围查询或未命中仍可能涉及间隙。

Q：怎么判断锁范围？

A：看执行计划、索引条件和 Performance Schema 的 data_locks。

9. 阶段小结

InnoDB行锁与间隙锁 的学习重点不是记住零散概念，而是把它放回真实系统：数据如何进入、如何存储、如何被查询、如何在并发下保持正确、如何在故障后恢复。掌握这些连接关系，才能从“会用”走向“能设计、能优化、能排障”。