1. 项目概述从一次线上事故说起那天下午监控告警突然响了提示核心订单表的写入延迟飙升。登录数据库一看一个看似简单的UPDATE orders SET status shipped WHERE user_id 123 AND status pending语句竟然卡住了十几秒后面堆积了几百个类似的更新请求。用SHOW ENGINE INNODB STATUS命令拉到最下面的TRANSACTIONS部分赫然发现一堆锁等待信息其中出现了lock_mode X locks gap before rec这样的字眼。那一刻我意识到问题出在了“间隙锁”上。这已经不是第一次因为对MySQL锁机制理解不深而踩坑了。很多开发者包括曾经的我对InnoDB锁的认识可能停留在“行锁”和“表锁”的层面顶多知道个“共享锁”和“排他锁”。但真正决定高并发场景下数据库是平稳运行还是“车祸现场”的往往是那些更精细的锁记录锁、间隙锁以及它们组合而成的临键锁。理解这三者就像是拿到了打开InnoDB并发控制大门的钥匙你能预判锁的冲突设计出更合理的索引和事务从根源上避免死锁和性能骤降。这篇文章我就结合多次“踩坑”和“填坑”的经验带你走一遍临键锁、间隙锁和记录锁的奇妙旅程把原理、现象和实战应对策略讲透。2. 基石认知InnoDB锁的基本分类与隔离级别在深入“三部曲”之前我们必须统一语境。InnoDB的锁机制和事务隔离级别是紧密耦合的不谈隔离级别讲锁就是耍流氓。2.1 共享锁与排他锁锁的基本态度首先是最基础的两种“锁态度”共享锁也叫S锁。它的态度是“分享”。事务A读取一行数据时可以加一个S锁。此时事务B也可以来读取这行数据并加S锁大家相安无事共同阅读。但任何事务都不能在这行数据上加排他锁。排他锁也叫X锁。它的态度是“独占”。事务A要更新或删除一行数据时必须加X锁。一旦加上其他事务既不能对这行数据加X锁也不能加S锁直到事务A释放锁。注意普通的SELECT语句在默认的REPEATABLE READ级别下是不加锁的快照读。如果要加锁需要显式使用SELECT ... FOR SHARES锁或SELECT ... FOR UPDATEX锁。2.2 事务隔离级别的核心影响SQL标准定义了四个隔离级别MySQL InnoDB默认是REPEATABLE READ。这个级别下InnoDB通过多版本并发控制和锁来共同保证隔离性。READ UNCOMMITTED几乎不加锁存在脏读生产环境禁用。READ COMMITTED每次读取都生成新的快照解决了脏读但存在不可重复读和幻读。在这个级别下InnoDB的间隙锁大部分会失效除了外键约束和唯一性检查等特殊情况这是理解锁行为差异的关键。REPEATABLE READ事务开始后第一个读操作建立一致性快照解决了不可重复读。同时InnoDB通过间隙锁在这个级别下很大程度上防止了幻读。我们讨论的“锁三部曲”主要在这个舞台上演。SERIALIZABLE所有读操作都自动转为SELECT ... FOR SHARE通过加锁来保证最强的隔离性能损耗大。我们接下来的所有实验和讨论如无特别说明均基于REPEATABLE READ隔离级别。3. 第一幕记录锁——精准的个体锁定记录锁是最直观、最基础的锁。顾名思义它就是锁住索引上的一条具体记录。3.1 记录锁如何工作假设我们有一张用户表users在id主键上有一个索引表中有数据id: 5, 10, 15, 20。-- 事务A BEGIN; SELECT * FROM users WHERE id 10 FOR UPDATE;这条语句会在id10这条记录的索引项上加一个排他记录锁。此时其他事务尝试SELECT ... FOR UPDATE或UPDATE、DELETEid10的记录都会被阻塞。其他事务可以正常SELECT快照读或者修改id5, 15, 20的记录。记录锁非常精准只影响目标记录本身不会干扰其“邻居”。它的目的就是保证在事务提交前目标记录不会被其他事务修改。3.2 记录锁的加锁对象是索引记录这里有一个至关重要的细节记录锁是加在索引记录上的而不是数据行本身。如果查询条件使用了非主键索引情况会复杂一些。假设users表还有一个age字段的索引且数据为(id, age): (1,20), (2,25), (3,20)。-- 事务A BEGIN; SELECT * FROM users WHERE age 20 FOR UPDATE;这条语句会做两件事在age索引树上找到所有age20的索引记录对应id1和id3并给这两条索引记录加上排他锁。由于SELECT *需要回表查询完整数据它还会根据查到的id1和id3回到主键索引树上对这两条主键记录也加上排他锁。实操心得这就是为什么低选择性的索引比如性别字段索引上加锁可能是灾难性的。锁住age20可能会锁住海量的索引记录和对应的主键记录极易引发大范围的锁等待和死锁。在设计需要高频更新的业务时索引选择必须慎重。4. 第二幕间隙锁——守护空虚的领域如果记录锁是锁住“有”那么间隙锁就是锁住“无”。它是InnoDB在REPEATABLE READ级别下防止幻读的主要手段。4.1 什么是幻读幻读是指一个事务内两次相同的范围查询看到了其他事务新插入的行。注意和“不可重复读”同一行数据被修改的区别。4.2 间隙锁的管辖范围间隙锁锁住的是索引记录之间的“间隙”或者第一个索引记录之前、最后一个索引记录之后的无穷大空间。这个区间是开区间。还用users表举例数据为id: 5, 10, 15, 20。那么索引上会形成以下几个间隙区间(-∞, 5)(5, 10)(10, 15)(15, 20)(20, ∞)-- 事务A BEGIN; SELECT * FROM users WHERE id BETWEEN 10 AND 20 FOR UPDATE;这条语句的目的不仅是锁住id10,15,20的记录更重要的是要防止其他事务在这个范围内插入新的记录。因此它除了在10,15,20上加记录锁还会在间隙(10,15)和(15,20)以及(20, ∞)上加间隙锁。注意(5,10)这个间隙没有被锁因为查询条件是id10。此时如果事务B尝试执行INSERT INTO users (id) VALUES (12);这个id12正好落在被锁住的(10,15)间隙内事务B会被阻塞直到事务A提交。这就防止了幻读。4.3 间隙锁的兼容性与冲突间隙锁有一个特殊属性它只用于阻止其他事务向这个间隙中插入记录。这意味着间隙锁与间隙锁之间是兼容的。不同的事务可以在同一个间隙上加间隙锁因为它们的目的都是防止插入彼此不冲突。间隙锁会与“插入意向锁”冲突。插入意向锁是INSERT操作在插入前的一种“打个招呼”的弱锁表示想往某个间隙插入。如果该间隙已被加了间隙锁插入意向锁就需要等待。注意事项正是由于间隙锁的存在在REPEATABLE READ级别下即使两个事务完全没有修改相同的记录也可能因为争夺同一个间隙的插入权而发生死锁。这是高并发插入场景下死锁的常见原因。5. 第三幕临键锁——记录与间隙的合体临键锁是记录锁和间隙锁的组合。它是InnoDB在REPEATABLE READ级别下加在非唯一索引上或者范围查询时的一种默认锁算法。5.1 临键锁的锁定范围临键锁会锁住一条索引记录以及这条记录之前的间隙。它的锁定区间是左开右闭。还是以users表的id: 5,10,15,20为例。如果执行-- 事务A BEGIN; SELECT * FROM users WHERE id 10 FOR UPDATE;在id是唯一索引如主键的情况下InnoDB优化为只加一个记录锁。但如果id是非唯一索引或者这是一个范围查询SELECT * FROM users WHERE id 10 AND id 20 FOR UPDATE;那么对于id15这条记录加的很可能就是临键锁。这个锁的覆盖范围是(10, 15]。它既锁定了id15这条记录本身防止修改删除也锁定了(10,15)这个间隙防止插入。5.2 临键锁的退化与升级理解临键锁的关键在于它的“动态性”退化为记录锁当查询条件命中一条唯一索引包含主键的等值记录时InnoDB知道不可能有另一条相同值的记录就没必要用间隙锁来防止幻读因此临键锁会退化为单纯的记录锁。退化为间隙锁当查询条件命中一条记录但实际扫描发现该记录不满足条件时例如WHERE id 12但id12不存在此时加的锁就是间隙锁锁住12所在的间隙(10,15)。作为默认锁算法在REPEATABLE READ级别下对于普通的SELECT ... FOR UPDATE或UPDATE/DELETE语句如果没有走唯一索引的等值查询InnoDB默认使用临键锁来同时防止幻读和当前读的数据被修改。6. 实战推演不同场景下的加锁分析理论需要结合实践。我们设计几个典型场景一步步推演加锁过程。请准备好你的“思维实验”环境。6.1 场景一主键等值查询表t 主键id 数据1, 4, 7, 10-- 事务A BEGIN; UPDATE t SET namea WHERE id 7;加锁分析id是主键等值查询命中记录id7。根据优化规则临键锁退化为记录锁。最终锁仅在id7这条主键索引记录上加X锁。其他事务可以插入id6或id8但不能修改或删除id7。6.2 场景二主键范围查询表和数据同上。-- 事务A BEGIN; SELECT * FROM t WHERE id 4 AND id 7 FOR UPDATE;加锁分析首先找到id4的记录加临键锁范围是(1, 4]。由于是范围查询的起点且id4存在锁住它。向后扫描找到id7。id7不满足id7的条件扫描停止。但为了锁定范围[4,7)需要锁住id7之前的间隙。因此会对id7加一个间隙锁锁住间隙(4,7)。最终锁id4的记录锁来自临键锁以及(4,7)的间隙锁。效果事务B不能修改id4也不能在(4,7)区间内插入任何记录如id5或id6。但可以插入id3或id8。6.3 场景三非唯一索引等值查询表t 有索引idx_k(k)数据(id,k): (1,3), (3,5), (5,5), (7,8), (10,10)。注意k5有两条记录。-- 事务A BEGIN; SELECT * FROM t WHERE k 5 FOR UPDATE;加锁分析过程稍复杂在idx_k索引树上找到第一条k5的记录对应id3加上临键锁锁住(3,5]区间假设前一条记录k3。由于k是非唯一索引k5可能有多条因此需要继续扫描下一条。找到第二条k5的记录对应id5同样加上临键锁。此时两个临键锁的区间可能是(第一条k5, 第二条k5]但实际上是连续的。扫描到下一条记录k8发现k!5停止扫描。但为了防止幻读需要在k8这条记录上加一个间隙锁锁住(5,8)这个间隙。由于是SELECT *需要回表。因此还会对主键索引上id3和id5的记录加记录锁。最终锁在idx_k索引上k5的两条索引记录上的临键锁本质是记录锁间隙锁以及(5,8)的间隙锁。在主键索引上id3和id5的记录锁。效果其他事务不能插入k5或k6,7的记录也不能修改id3或id5的主键记录。这个场景清晰地展示了非唯一索引下锁的扩散也是死锁的高发区。7. 死锁现场间隙锁与插入意向锁的碰撞理解了锁的原理我们就能诊断和预防死锁。下面是一个经典的间隙锁死锁场景。表结构accounts 有唯一索引account_id数据(1001), (1003), (1005)。时间线事务ABEGIN; SELECT * FROM accounts WHERE account_id 1002 FOR UPDATE;1002不存在加锁在account_id索引上对(1001, 1003)这个间隙加间隙锁。事务BBEGIN; SELECT * FROM accounts WHERE account_id 1002 FOR UPDATE;同样操作加锁同样成功获得了(1001, 1003)这个间隙上的间隙锁间隙锁之间兼容。事务AINSERT INTO accounts (account_id) VALUES (1002);尝试获取(1001, 1003)间隙上的插入意向锁。冲突插入意向锁与事务B持有的间隙锁冲突事务A阻塞等待事务B。事务BINSERT INTO accounts (account_id) VALUES (1002);尝试获取(1001, 1003)间隙上的插入意向锁。冲突插入意向锁与事务A持有的间隙锁冲突事务B阻塞等待事务A。至此事务A和事务B互相等待死锁产生。InnoDB的死锁检测机制默认开启会在短时间内通过innodb_deadlock_detect控制发现这个循环等待并选择回滚其中一个事务通常是权重较小即修改行数较少的事务。排查技巧实录当发生死锁时第一时间查看SHOW ENGINE INNODB STATUS的输出找到LATEST DETECTED DEADLOCK部分。它会详细记录两个事务最后执行的SQL、各自持有的锁和等待的锁。根据这个信息结合上面的锁原理分析几乎可以定位所有死锁的根源。常见的解决思路包括1. 调整事务逻辑顺序让所有事务以相同的顺序访问资源2. 在业务允许的情况下使用较低的隔离级别如READ COMMITTED来避免间隙锁3. 对热点行的操作进行队列化或合并处理。8. 性能调优与锁优化实战指南锁是保证一致性的必要手段但不当的使用会成为性能瓶颈。以下是一些核心的优化思路。8.1 索引设计是锁优化的源头尽量使用唯一索引等值查询唯一索引临键锁会退化为记录锁锁的范围最小冲突概率最低。避免低选择性索引上的加锁查询在“性别”字段索引上FOR UPDATE可能锁住表中一半的数据务必避免。让查询尽可能通过索引精准定位减少全表扫描。全表扫描会对所有记录及其间隙加锁在RR级别下是灾难性的。确保你的WHERE条件能有效利用索引。8.2 事务设计原则事务要短小快尽快提交事务释放锁。避免在事务内执行远程调用、文件IO等耗时操作。访问资源的顺序要一致多个事务如果都以A-B-C的顺序访问行就不容易产生死锁。如果事务1是A-B事务2是B-A死锁风险就高。基于主键或唯一键更新这能最大程度利用记录锁减少锁范围。8.3 SQL语句编写技巧慎用范围查询特别是FOR UPDATE的范围查询会加临键锁锁住一个范围。评估业务是否真的需要。避免不必要的FOR UPDATE如果只是要读取最新数据在READ COMMITTED级别下用普通SELECT即可或者使用SELECT ... LOCK IN SHARE MODES锁替代X锁兼容性更好。考虑使用乐观锁对于冲突概率不高的场景在表中增加一个version字段通过UPDATE ... SET version new_version WHERE id ? AND version old_version的方式更新利用CAS思想避免长时间加锁。8.4 系统参数与监控监控锁等待关注information_schema.INNODB_LOCKS和INNODB_LOCK_WAITS视图定期检查SHOW ENGINE INNODB STATUS中的锁信息。调整innodb_lock_wait_timeout控制单个锁等待的超时时间避免一个锁等太久拖垮整个系统。默认50秒对于OLTP系统可能偏长。理解innodb_deadlock_detect默认开启能自动检测并回滚死锁。在超高并发场景下检测本身可能有性能损耗可考虑关闭但需做好超时处理。9. 常见问题排查速查表在实际运维中以下问题非常典型。我将其整理成表方便快速对照排查。问题现象可能原因排查思路与解决方案更新/删除语句长时间阻塞1. 目标记录被其他事务的X锁占用。2. 目标记录所在的间隙被其他事务的间隙锁占用尝试插入时。1. 执行SHOW PROCESSLIST;找到阻塞者。2. 使用SELECT * FROM information_schema.INNODB_LOCKS;和INNODB_LOCK_WAITS;查看锁等待链。3. 优化事务缩短持有锁的时间。INSERT语句阻塞1. 插入的目标间隙被其他事务加了间隙锁或临键锁。2. 插入的记录与现有记录主键/唯一键冲突。1. 检查是否有并发的SELECT ... FOR UPDATE范围查询。2. 考虑在业务低峰期执行批量插入或使用READ COMMITTED隔离级别需评估幻读风险。频繁出现死锁1. 多个事务以不同顺序访问相同的行或间隙。2. 并发SELECT ... FOR UPDATE不存在的记录后插入引发间隙锁死锁见第7节。1. 分析死锁日志确定冲突资源。2. 统一事务内的数据访问顺序。3. 对于“查无此记录则插入”的逻辑使用INSERT ... ON DUPLICATE KEY UPDATE或先尝试插入再处理唯一键冲突异常。全表扫描导致锁表在RR级别下一个大事务对无索引的字段进行更新WHERE non_indexed_column ?会导致全表所有记录和间隙加锁。1. 紧急处理定位并Kill掉该长事务。2. 根本解决为查询条件添加索引。3. 优化SQL避免全表扫描的加锁操作。从库延迟增大主库上某个长事务持有大量锁阻塞了其他事务的提交进而影响了binlog的生成和传输速度。1. 监控主库的长事务列表SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started ASC;2. 优化或拆分该长事务。理解MySQL InnoDB的锁尤其是临键锁、间隙锁和记录锁这套组合拳是一个从“被动踩坑”到“主动避坑”的过程。它没有银弹需要你根据具体的业务场景、数据模式和并发压力在数据一致性和系统性能之间做出精妙的权衡。我的经验是在设计之初就考虑到锁的粒度建立合适的索引编写高效且意图明确的SQL远比出了问题再去救火要轻松得多。下次当你写下FOR UPDATE时不妨在脑海里快速推演一下它可能会在索引树上画出怎样的锁范围这或许就能帮你避开一个深夜告警。
