1. 从一次线上事故说起为什么需要深入理解临键锁那天晚上我正在处理一个线上报表系统的慢查询告警。系统在凌晨批量处理订单数据时一个原本运行顺畅的SELECT ... FOR UPDATE查询突然卡住了连带拖慢了后续十几个依赖它的任务。登录数据库一看熟悉的SHOW ENGINE INNODB STATUS输出里LATEST DETECTED DEADLOCK部分赫然显示着lock_mode X locks gap before rec这样的字眼。又是它——临键锁Next-Key Lock。这已经不是第一次因为它而半夜爬起来处理问题了。对于很多从其他数据库转过来或者习惯了在低并发、小数据量环境下开发的工程师来说MySQL的锁机制特别是临键锁常常是一个“黑盒”。我们可能知道要给高频更新的字段加索引知道事务要尽量短小但一旦涉及到范围查询、间隙锁定问题就变得微妙而复杂。临键锁是InnoDB默认的行锁算法它不仅仅是锁住你查询到的那一行数据还会锁住一个“区间”。这个设计初衷是为了解决“幻读”问题保证在“可重复读”隔离级别下的数据一致性但它带来的副作用就是锁的范围可能远超你的预期极易引发死锁和性能瓶颈。理解临键锁不是为了应付面试时那几个经典问题而是为了在真实的生产环境中当你面对诡异的锁等待超时、难以复现的死锁或者无法解释的性能抖动时能有一把锋利的“手术刀”精准地定位到问题的根源。它关乎系统的稳定性和你深夜的睡眠质量。接下来我会结合原理、实战场景和大量的示例带你彻底拆解这个既关键又容易让人困惑的机制。2. 临键锁的核心原理不止锁一行更是锁一个“世界”要理解临键锁我们必须先把它放在InnoDB的锁体系里看。InnoDB实现了两种标准的行级锁共享锁S Lock允许事务读一行数据。排他锁X Lock允许事务更新或删除一行数据。而行锁的具体实现方式就是锁算法。临键锁是其中最重要的一种。2.1 锁算法的“三驾马车”InnoDB有三种行锁算法它们共同构成了临键锁的基础记录锁Record Lock这是最直观的锁它锁住索引记录本身。比如SELECT * FROM t WHERE id 10 FOR UPDATE;就会在id10这个索引记录上加一个X型的记录锁。它只锁这一条具体的记录。间隙锁Gap Lock这是临键锁的灵魂所在。它锁住的是索引记录之间的“间隙”是一个开区间。例如表中存在id5和id10的记录那么间隙锁可以锁住(5, 10)这个区间。间隙锁的唯一作用就是防止其他事务在这个间隙中插入新的记录。它不锁任何已有的记录。间隙锁是“可共享”的意思是多个事务可以在同一个间隙上加间隙锁都是为了防止插入它们之间不会冲突。临键锁Next-Key Lock这是记录锁和间隙锁的组合。它锁住的是“索引记录本身”加上“该记录之前的间隙”。它是一个左开右闭的区间(previous_record, current_record]。例如如果存在记录id10那么一个在id10上的临键锁锁定的范围可能是(5, 10]假设前一条记录是5。关键点在默认的“可重复读”隔离级别下InnoDB对于行锁的默认算法就是临键锁。而“读已提交”隔离级别下通常只使用记录锁间隙锁会被禁用除了一些特殊情况如外键约束和唯一性检查。2.2 临键锁如何解决幻读“幻读”是指在一个事务内两次执行相同的查询第二次看到了第一次没有看到的新行这些新行是其他事务插入的。临键锁通过锁定“可能被插入新记录的间隙”来杜绝幻读。我们来模拟一个场景。假设表user有一个唯一索引 onage现有记录age20和age30。事务A执行-- 事务A START TRANSACTION; SELECT * FROM user WHERE age 25 FOR UPDATE; -- 假设想锁住年龄25的用户在可重复读级别下这条语句会加临键锁。它需要找到第一个满足age25的记录即age30。那么它会在age30这条记录上加临键锁。这个临键锁的范围是多少呢它锁住的是age30这条记录本身记录锁加上它前面的间隙间隙锁。前一条记录是age20所以锁定的区间是(20, 30]。此时事务B尝试执行-- 事务B INSERT INTO user (age) VALUES (25); -- 尝试插入一个age25的用户 INSERT INTO user (age) VALUES (29); -- 尝试插入一个age29的用户这两个插入操作都会失败因为值25和29都落在了被事务A锁定的间隙(20, 30)之内。事务B会被阻塞直到事务A提交。这样在事务A提交前任何年龄在20到30之间不包括20包括30的新用户都无法被插入从而保证了事务A两次执行SELECT ... FOR UPDATE看到的结果集是一致的幻读被防止了。注意这里有一个极其重要的细节。临键锁锁的是索引。如果上面的查询条件age25没有用到索引或者用的是非唯一索引锁的范围可能会更大甚至升级为表锁。这是很多死锁的根源。2.3 唯一索引 vs 非唯一索引锁范围的差异锁的范围高度依赖于索引的类型。唯一索引包括主键上的等值查询当用唯一索引做等值查询时InnoDB的优化器知道最多只会返回一条记录。此时它只会退化为一个记录锁而不会加临键锁。因为既然值是唯一的就不可能有其他记录插入到这个“值”所在的位置。SELECT * FROM user WHERE id 100 FOR UPDATE; -- id是主键这条语句只会在id100这条记录上加X锁不会锁任何间隙。非唯一索引上的等值查询情况就复杂了。因为非唯一索引允许重复值所以InnoDB必须防止其他事务插入相同的值。因此它除了在匹配到的所有索引记录上加记录锁还会在这些记录之间的间隙上加间隙锁。-- 假设在 score 字段上有一个非唯一索引现有记录 score80, score80, score90。 SELECT * FROM student WHERE score 80 FOR UPDATE;这条语句会在所有score80的索引记录上加记录锁。在第一个score80之前的间隙比如(-∞, 80)和最后一个score80与下一个值score90之间的间隙即(80, 90)上加间隙锁。 这样其他事务就无法再插入score80的新记录了因为会被(80,90)或更早的间隙锁挡住也无法插入score在80到90之间的记录。范围查询无论索引是否唯一对于、、BETWEEN、LIKE等范围查询InnoDB会对其扫描到的索引范围加上临键锁。这是最需要警惕的情况锁的范围可能非常大。SELECT * FROM log WHERE create_time 2023-10-01 FOR UPDATE;如果create_time索引的最后一个值是2023-12-01那么这个锁可能会一直锁到“正无穷”一个特殊的 supremum 记录即(‘2023-10-01’, ∞)这会彻底阻塞这个时间点之后的所有插入。理解这些差异是设计索引和编写SQL时避免过度加锁的关键。3. 实战推演临键锁引发的典型死锁场景与排查理论说再多不如看一个真实的“车祸现场”。下面是一个经典的非唯一索引等值查询死锁案例。3.1 死锁现场还原我们有一个简单的账户表CREATE TABLE account ( id bigint PRIMARY KEY AUTO_INCREMENT, user_id varchar(32) NOT NULL, balance decimal(10,2) NOT NULL, KEY idx_user_id (user_id) -- 注意这是一个非唯一索引 );现有数据(id1, user_id‘A’, balance100),(id2, user_id‘B’, balance200)。现在两个并发事务按如下顺序执行时间点事务1事务2T1BEGIN;BEGIN;T2SELECT * FROM account WHERE user_id ‘A’ FOR UPDATE;T3SELECT * FROM account WHERE user_id ‘B’ FOR UPDATE;T4SELECT * FROM account WHERE user_id ‘B’ FOR UPDATE;(等待)T5SELECT * FROM account WHERE user_id ‘A’ FOR UPDATE;(死锁发生!)3.2 死锁原因逐步剖析我们来一步步拆解每个操作加的锁T2时刻事务1执行WHERE user_id ‘A’ FOR UPDATE。由于user_id是非唯一索引事务1会在user_id‘A’的索引记录上加记录锁假设对应主键id1。加间隙锁。user_id索引上的记录排序可能是(‘A’ ‘B’)。事务1会在‘A’之前和之后的间隙加锁。‘A’之前可能是负无穷之后是到‘B’的间隙。所以它锁定了(-∞, ‘A’]的临键锁包含记录‘A’和(‘A’ ‘B’)的间隙锁。关键来了它锁住了(‘A’ ‘B’)这个间隙。T3时刻事务2执行WHERE user_id ‘B’ FOR UPDATE。同理事务2会在user_id‘B’的索引记录上加记录锁对应id2。加间隙锁。它会锁定(‘A’ ‘B’]的临键锁包含记录‘B’和(‘B’ ∞)的间隙锁。注意它也请求了对(‘A’ ‘B’)这个间隙的锁作为临键锁的一部分。此时事务2对(‘A’ ‘B’)间隙锁的请求会被阻塞吗不会因为间隙锁是共享的。事务1已经持有了(‘A’ ‘B’)的间隙锁S锁事务2也可以申请并获得同一个间隙上的间隙锁S锁。所以T3时刻事务2成功执行持有了user_id‘B’的记录锁和相关的间隙锁。T4时刻事务1尝试获取user_id‘B’的记录锁。事务1执行SELECT ... FOR UPDATE WHERE user_id ‘B’。它需要获取user_id‘B’索引记录上的X锁记录锁。但是这个记录锁已经被事务2在T3时刻持有了X锁。X锁与X锁是互斥的。因此事务1被阻塞进入锁等待状态。T5时刻事务2尝试获取user_id‘A’的记录锁。事务2执行SELECT ... FOR UPDATE WHERE user_id ‘A’。它需要获取user_id‘A’索引记录上的X锁。这个记录锁已经被事务1在T2时刻持有了。因此事务2也被阻塞。此时事务1在等待事务2释放user_id‘B’的锁事务2在等待事务1释放user_id‘A’的锁。循环等待形成死锁发生InnoDB的死锁检测机制默认开启会立刻发现这个循环等待并选择其中一个事务通常是回滚代价较小的那个进行回滚让另一个事务继续执行。3.3 如何排查与解读死锁信息当发生死锁时最快的诊断方法是查看SHOW ENGINE INNODB STATUS命令输出中的LATEST DETECTED DEADLOCK部分。它会详细记录导致死锁的两个事务最后执行的语句、各自持有的锁和等待的锁。对于上面的例子输出可能包含类似这样的信息已简化LATEST DETECTED DEADLOCK ... *** (1) TRANSACTION: TRANSACTION 12345, ACTIVE 10 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s) MySQL thread id 100, OS thread handle ..., query id 1000 ... updating SELECT * FROM account WHERE user_id ‘B’ FOR UPDATE *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 100 page no 5 n bits 72 index idx_user_id of table test.account trx id 12345 lock_mode X locks rec but not gap waiting Record lock, heap no 3 PHYSICAL RECORD: ... (这里显示‘B’索引记录的信息) *** (2) TRANSACTION: TRANSACTION 67890, ACTIVE 15 sec starting index read mysql tables in use 1, locked 1 3 lock struct(s), heap size 1136, 2 row lock(s) MySQL thread id 200, OS thread handle ..., query id 2000 ... updating SELECT * FROM account WHERE user_id ‘A’ FOR UPDATE *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 100 page no 5 n bits 72 index idx_user_id of table test.account trx id 67890 lock_mode X locks rec but not gap Record lock, heap no 2 PHYSICAL RECORD: ... (这里显示‘A’索引记录的信息) *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 100 page no 5 n bits 72 index idx_user_id of table test.account trx id 67890 lock_mode X locks rec but not gap waiting Record lock, heap no 3 PHYSICAL RECORD: ... (这里显示‘B’索引记录的信息)解读关键点lock_mode X locks rec but not gap表示这是一个记录锁X锁。可以看到事务(1)在等待user_id‘B’的记录锁而这个锁正被事务(2)持有。事务(2)持有user_id‘A’的记录锁同时在等待user_id‘B’的记录锁。虽然死锁的直接原因是记录锁互斥但根本诱因是两个事务以不同顺序访问相同的资源索引记录A和B并且在访问间隙锁时没有冲突但在升级到需要互斥的记录锁时形成了环。3.4 规避此类死锁的实战心得以固定顺序访问资源这是解决此类死锁最有效的方法。在业务代码中如果需要对多个行加锁比如转账需要锁住A账户和B账户约定一个全局的排序规则例如始终按照user_id升序或主键id升序的顺序进行加锁。在上面的例子中如果两个事务都先锁user_id‘A’再锁user_id‘B’那么后发起的事务会在第一步就被阻塞不会形成循环等待。使用主键或唯一索引进行锁定如果业务允许尽量使用SELECT ... FOR UPDATE WHERE id ?的方式。如原理部分所述唯一索引上的等值查询会退化为记录锁不会加间隙锁从而大大减少锁冲突的范围。在上例中如果事务通过id来锁定账户死锁就不会发生。降低事务隔离级别如果业务能接受“读已提交”隔离级别下的幻读现象很多业务场景其实可以接受可以在会话或全局设置SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;。在该级别下普通的查询不会加间隙锁上述死锁场景的概率会骤降。但务必评估幻读对业务逻辑的影响。保持事务短小精悍事务持有锁的时间越短发生冲突的窗口期就越小。尽快提交事务不要在事务内执行网络调用、复杂的计算或人机交互。4. 边界案例与特殊规则那些意料之外的锁行为临键锁的规则有一些边界情况和优化策略不了解它们很容易掉进坑里。4.1 “唯一索引”的边界NULL值与“间隙”的尽头唯一索引上的NULL值唯一索引允许存在多个NULL值。因此对WHERE unique_key IS NULL的查询InnoDB无法使用记录锁退化因为它可能匹配多行。它会使用临键锁来锁定所有NULL值所在的区间通常是从负无穷到第一个非NULL值之间的间隙。“上确界”记录索引中最大的记录之后被认为存在一个“上确界”记录。任何大于最大索引值的范围查询其临键锁都会锁到(max_value, ∞)这个区间。例如SELECT * FROM t WHERE id 100 FOR UPDATE;如果表中最大id是200那么这个锁的范围是(200, ∞)。4.2 “间隙锁”的兼容性与冲突这是最容易混淆的点之一。务必记住这张表请求锁类型 vs 已存在锁类型记录锁 (X)记录锁 (S)间隙锁 (X/S)临键锁 (X)临键锁 (S)记录锁 (X)冲突冲突兼容冲突冲突记录锁 (S)冲突兼容兼容冲突兼容间隙锁 (X/S)兼容兼容兼容兼容兼容临键锁 (X)冲突冲突兼容冲突冲突临键锁 (S)冲突兼容兼容冲突兼容核心结论间隙锁只和插入意向锁冲突。间隙锁之间、间隙锁与记录锁/临键锁之间都是兼容的。这就是为什么上面死锁案例中事务1和事务2可以同时持有(‘A’ ‘B’)的间隙锁。记录锁与记录锁、记录锁与临键锁如果覆盖同一条记录的X锁是互斥的。这是死锁的直接原因。插入意向锁是一种特殊的间隙锁表示事务打算在某个间隙插入记录。它会与已有的间隙锁或临键锁冲突。例如事务A持有(5,10)的间隙锁事务B想插入id7的记录它需要获取(5,10)上的插入意向锁这会被事务A阻塞。4.3 半一致性读与锁退化在“读已提交”隔离级别下或者当innodb_locks_unsafe_for_binlog参数开启时不推荐InnoDB使用一种叫“半一致性读”的优化。对于不符合WHERE条件的行InnoDB会提前释放锁。这可能导致一些诡异的现象但在“可重复读”下不会发生。5. 性能优化与最佳实践让锁为你所用而非与你为敌理解了临键锁的机制我们就可以主动设计系统来避免锁竞争提升并发性能。5.1 索引设计是锁优化的第一道防线尽量使用唯一索引进行等值查询如前所述这是减少锁范围最有效的手段。将高频更新的条件列改为唯一索引或者通过“业务字段唯一后缀”的方式创建唯一索引。避免在非唯一索引上进行范围查询或FOR UPDATE如果业务必须如此考虑能否通过其他方式实现比如使用主键ID进行分批处理。小心使用复合索引临键锁锁住的是索引记录。对于复合索引(a, b)查询WHERE a 1会锁住所有a1的索引记录及其间隙即使b的值不同。这可能导致比预期更大的锁范围。5.2 SQL编写与事务控制的艺术精确查询避免全表/全索引扫描SELECT * FROM t WHERE status ! ‘DELETED’ FOR UPDATE;这样的语句如果status没有索引会触发全表扫描并对扫描到的每一行及间隙加锁极易导致锁表。务必为查询条件添加合适的索引。使用LIMIT子句对于需要锁定多行的操作使用SELECT ... FOR UPDATE LIMIT N可以控制锁定的行数减少锁持有时间和范围。但要注意配合ORDER BY使用固定排序否则每次锁定的行可能不同在业务逻辑上可能有问题。将大事务拆分为小事务这是黄金法则。如果一个事务需要更新十万行考虑拆分成每次处理一千行的多个小事务。这不仅能减少锁的持有时间还能降低死锁概率和回滚代价。在事务外完成准备工作尽可能将数据查询、计算等不涉及修改的操作放在事务之外事务内只包含必要的写操作。5.3 监控与诊断工具链SHOW ENGINE INNODB STATUS死锁排查的第一现场必须掌握其解读方法。information_schema库中的表INNODB_TRX查看当前所有运行的事务。INNODB_LOCKS查看当前出现的锁信息MySQL 8.0中已被performance_schema.data_locks替代。INNODB_LOCK_WAITS查看锁等待关系MySQL 8.0中已被performance_schema.data_lock_waits替代。performance_schema(MySQL 5.7/8.0)提供了更强大和持久的锁监控能力。可以开启相关消费者来记录历史锁信息。-- 在MySQL 8.0中查看当前锁信息 SELECT * FROM performance_schema.data_locks WHERE LOCK_TYPE ‘RECORD’\G SELECT * FROM performance_schema.data_lock_waits\Gpt-deadlock-logger(Percona Toolkit)一个非常实用的命令行工具可以持续监控数据库并将死锁信息记录到另一个表中便于后续分析。临键锁是InnoDB高并发能力的基石也是并发问题的主要来源。把它理解透彻就像是拿到了数据库并发世界的“地图”和“导航”。下次再遇到锁等待或死锁你不会再感到茫然而是能冷静地打开诊断工具沿着锁的路径一步步找到问题的症结所在。真正的熟练来自于对原理的深刻认知和大量实践中的复盘总结。