MySQL InnoDB锁机制详解：行锁、间隙锁与死锁排查实战

前阵子帮一个团队排查线上死锁，报错日志特别典型：两条 UPDATE 执行时间只差了几毫秒，最后各自等到了对方持有的锁。开发同事的第一反应是“是不是SQL写错了”，但等我把锁等待链一条条拆开，他们才明白问题根本不在SQL语法，而在事务的加锁顺序和InnoDB的锁实现细节上。这也是我总在团队里强调的一句话：如果不懂锁，就谈不上真正懂MySQL的并发控制。

这篇文章想跟你聊的，就是MySQL（主要是InnoDB引擎）里锁的实现细节。我会从锁的类型和粒度讲起，然后钻到InnoDB的锁结构、隐式锁、死锁检测机制，再用真实案例把排查过程完整走一遍。内容面向后端开发、DBA和有志于搞懂MySQL面试核心题的同学，能帮你把“行锁”“间隙锁”“死锁”这些概念串成一条能落地的知识链，而不是靠背结论应付面试。

1. 先搞清楚一个基础问题：MVCC都解决“读”了，为什么还要锁

很多人刚接触InnoDB时会有个困惑：不是有MVCC多版本并发控制吗？读和写不就能互不阻塞了吗？那锁到底在锁什么？

要理解MySQL的锁实现细节，第一步恰恰是要把MVCC和锁的边界划清楚。MVCC解决的问题是“快照读”和“当前写”之间的阻塞关系，它能让普通SELECT不用等待正在进行的修改事务提交；但MVCC并没有解决“多个写事务同时修改同一行”的问题。两个事务同时对同一条记录做UPDATE，如果都没有锁机制，那就必然出现丢失更新。所以InnoDB设计了一套组合拳：MVCC负责让读不加锁也能拿到一致快照，锁负责保证写操作之间严格串行化。

1.1 MVCC的快照读与不加锁读

MVCC的核心手段是undo log版本链和ReadView。每个事务在REPEATABLE READ隔离级别下首次执行普通SELECT时，会生成一个ReadView，用来决定当前事务能看到哪个版本的记录。记录被修改时，旧版本不会立刻覆盖，而是通过undo log串成一条版本链，新版本记录上还带着trx_id。

普通SELECT走的就是快照读，它不需要加任何锁，这是InnoDB并发读性能高的根源。注意，即便是快照读，也要根据ReadView去版本链里找可见版本。如果不对应版本，就顺着undo回滚指针往上找，找到满足可见性判断的历史版本为止。整个过程只读undo，不触及其他事务持有的行锁，天然不会产生阻塞。

但快照读也有局限：它读到的可能是历史版本，而不是所有事务提交后的最新值。有些业务场景必须看到最新结果，比如“先查再改”的库存扣减、订单状态流转、账户余额增减，这类操作不能容忍读到旧版本后再覆盖写。于是有了当前读，以及当前读需要加的锁。

1.2 当前读与三种加锁操作

当前读也常被叫作“锁定读”，它读取的一定是记录的最新已提交版本，并在读取时对目标记录加锁。触发当前读的操作主要有四类：

sql复制-- 显式锁定读
SELECT ... FOR UPDATE;
SELECT ... FOR SHARE; （MySQL 8.0，之前的 LOCK IN SHARE MODE 同理）

-- 隐式锁定读（DML天然就是当前读）
UPDATE ...;
DELETE ...;

-- INSERT 也一样要加锁，只是情况更特殊
INSERT ...;

当一条UPDATE执行时，InnoDB会先以当前读的方式定位到目标记录，拿到记录后加上排他锁（X锁），再去做数据修改。为什么UPDATE不用快照读？因为UPDATE之后还要写，如果基于一个旧版本去覆盖新值，就会产生“丢失更新”，这是事务隔离绝不允许的。

SELECT ... FOR UPDATE和SELECT ... FOR SHARE则是开发者主动放弃快照读，强制读取最新版本并加锁。它们对应的语义是“我要基于这条记录做后续业务操作，期间不允许其他人修改”。SELECT ... FOR SHARE加的是共享锁（S锁），多个事务可以同时对同一行加S锁；而SELECT ... FOR UPDATE加的是排他锁（X锁），与任何其他锁都互斥。

注意：这里的互斥要考虑锁模式兼容矩阵。S与S兼容，S与X不兼容，X与任何锁都不兼容。但实际还要结合锁类型和隔离级别综合判断，这一点后文会展开。

1.3 隔离级别一变，锁的范围全变

另一个关键点是：同一个SQL，在不同隔离级别下，加锁范围可能完全不同。InnoDB默认隔离级别是REPEATABLE READ（可重复读），在这个级别下InnoDB不仅要防止已提交的事务修改目标行，还要防止其他事务往目标范围内插入新行，也就是防幻读。防幻读靠的就是间隙锁（Gap Lock）和临键锁（Next-Key Lock）。

如果你把隔离级别调整成READ COMMITTED（读已提交），InnoDB就会放弃间隙锁，只对命中的索引记录加记录锁（Record Lock）。这样并发插入能力会上升，但代价是同一事务两次快照读可能读到不同结果，你需要通过其他手段保证业务逻辑一致。

在实际生产环境里，如果binlog格式是ROW，很多团队会把隔离级别调成READ COMMITTED来降低锁冲突，因为ROW格式下事务执行结果已经确定，不再依赖REPEATABLE READ的间隙锁来确保主从一致。但这么调整的前提是业务可以接受“当前读会话之间可能插入新数据”的隔离语义。不能为了省事一刀切，要逐业务评估。

2. 行锁、间隙锁、临键锁与表锁，这些“锁”到底锁住了什么

我第一次接触InnoDB锁分类时，觉得Record Lock、Gap Lock、Next-Key Lock这几个概念特别绕。后来在排查死锁过程中反复看日志，才真正理解它们不是三个独立功能，而是“为了在不同场景下保证数据不异常”而设计的一套连续方案。

2.1 Record Lock、Gap Lock、Next-Key Lock：从语义到实例

Record Lock是记录锁，锁的是索引记录本身。它是最直观的行级锁，锁住某行后，其他事务不能修改和删除这一行。很多人以为UPDATE就是单纯锁住“那一行”，这个说法在“通过唯一索引等值命中且记录存在”时是对的，因为InnoDB会退化为Record Lock。但在更多查询场景下，锁的不只是目标记录。

举个例子，user表里有id主键，id从1到100，你按id=1做主键等值查询倒是简单。但如果写的是这样一条SQL。

sql复制SELECT * FROM user WHERE age BETWEEN 20 AND 30 FOR UPDATE;

假设age列有普通索引，扫描命中了多条记录。InnoDB会怎么加锁？

它会从二级索引age的首个满足条件的记录开始，一直扫描到第一个不满足条件的记录为止，给扫描路径上所有满足条件的二级索引记录加X锁，同时给对应的主键索引记录加X锁。对于这个过程中满足条件但不存在的区间，还要加Gap Lock，防止其他事务在两次查询之间插入满足条件的新记录。

Gap Lock锁的是一个开区间，只锁区间不锁记录。在REPEATABLE READ下执行范围查询时，InnoDB会对扫描区间内的“间隙”加锁，让其他事务无法在这个区间插入新数据，这样就阻塞了幻读路径。

Next-Key Lock是Record Lock和Gap Lock的结合体，等价于“记录锁加前一个间隙的间隙锁”，它锁的是左开右闭区间。比如表中id有1、5、9三条记录，Next-Key Lock可能锁住的范围是(1,5]、(5,9]这类区间，既锁住记录5，又防止其他事务往1到5之间的间隙插入新记录。因为间隙锁不锁记录本身，所以仅仅用Gap Lock做不到锁住已有记录，只有跟Record Lock组合成Next-Key Lock，才能完整保证一次范围读不会出现幻读。

有一个特别容易忽略的细节：在唯一索引等值查询且记录存在时，InnoDB会主动把Next-Key Lock退化成Record Lock。因为唯一索引已经能保证这条记录只有一个，不可能有另一个事务在它前面或后面插入重复值，幻读风险不存在，没必要用更大的锁范围。

如果是唯一索引等值查询但记录不存在，情况又不一样。此时InnoDB会在“这条记录应该所在的位置”附近加Gap Lock，阻塞其他事务插入能匹配该条件的记录。很多人在面试里说“唯一索引只加行锁”，没考虑到记录不存在时仍会加间隙锁——这正是实操经验和书本知识的区别。

2.2 意向锁：表锁与行锁之间的“信号灯”

InnoDB的行锁和表锁不是割裂的。假设事务A对user表的1号和2号记录加了X锁，事务B想对整个user表加一个X表锁。如果没有意向锁机制，InnoDB必须逐行扫描判断表里是否存在行锁，成本很高。有了意向锁，事务A在加行锁之前，会先在表级别加一个“意向排他锁”（IX锁），事务B做表锁判断时，一看到IX锁就知道表内存着行锁，没必要再扫描。

意向锁分为意向共享锁（IS）和意向排他锁（IX），它们的加锁规则可以概括为：在事务对某行记录加S锁前，必须先对表加IS锁；在事务对某行记录加X锁前，必须先对表加IX锁。

意向锁之间是互相兼容的，两个事务可以同时对同一张表持有IS和IX锁。为什么能兼容？因为意向锁只是声明“我要去行级别加锁了”，并不真正控制资源；真正的冲突判断还是发生在行级锁上。但表级S锁、表级X锁与意向锁之间是不兼容的，因为表级S/X锁要锁整张表，如果允许表级S锁和IX锁共存，就意味着一个事务正握着表读锁的同时，另一个事务还在修改表内某行，这会导致数据边界混乱。

我在DBA日常巡检里经常看到的一种现象：某条ALTER TABLE语句迟迟不执行，干等半天。一查，通常是有长事务在某个表上持有IX锁，ALTER操作需要的表级排他锁（MDL或者AUTO-INC相关的锁）无法获取。这种阻塞不是行锁打架，而是“表锁意愿”被长事务挡住。理解了意向锁，这类问题一眼就能定位。

2.3 插入意向锁和 AUTO-INC 锁的细节差异

在索引记录之间插入数据时，InnoDB有一种专门的锁——插入意向锁（Insert Intention Lock）。它本质上是Gap Lock的一种特殊表现，但它的锁语义比较友好：多个事务可以同时往同一个间隙里插入记录，只要插入的位置不冲突即可。

你可以这样理解：A事务锁住了(10, 20)这个间隙，B事务想在间隙中间插入id=15的记录，B必须等待A释放间隙锁。但如果B要插入id=25的位置，那就跟A的锁区间没有重叠，完全可以并发执行。InnoDB会为每个等待间隙锁的插入事务维护一个插入意向锁，它排队的粒度是“目标位置”，而不是整个间隙。

设计这套机制的目的很明确：让“插入记录”对“同区间其他不同位置的插入”保持兼容。如果锁实现细节做得太粗，两个业务往同一张表的不同位置插入数据也会互相阻塞，那写入性能会差到没法接受。

AUTO-INC锁则是表级锁的一种，用于控制自增列的并发分配。当执行INSERT且自增列没有显式赋值时，InnoDB需要给该表加一个AUTO-INC表锁，拿到下一个自增值后再插入，然后释放。注意，AUTO-INC锁不是事务结束后才释放，而是在INSERT语句执行完毕后就会释放，目的是让多条INSERT能交错获取自增id，又不会产生重复值。

MySQL有一个参数innodb_autoinc_lock_mode，从0到2可选。默认值在5.7是1，在8.0是2。0是传统模式，每条INSERT都持AUTO-INC锁到语句结束；1是批量插入时使用表锁，但普通单条INSERT用轻量互斥锁；2是交错模式，所有插入都用互斥锁，能显著提升并发，但在statement格式的binlog下可能导致自增值不连续，主从复制时产生不一致。如果你的binlog_format是ROW，把innodb_autoinc_lock_mode设为2是最优解；如果还在用statement格式，就得谨慎。

3. InnoDB 加锁的内部实现：一条 UPDATE 是怎么“锁上”的

前面讲的是锁的“种类”，这一节我想深入InnoDB的内部实现，回答几个更底层的疑问：一条UPDATE到底会往内存里写入什么样的锁对象？为什么有时候执行计划走了二级索引，主键上也会同时出现锁？一条记录刚插入时没看到锁对象，它算有锁吗？

3.1 从执行计划到锁定位

当MySQL Server层把一条UPDATE语句解析优化后，会生成执行计划，然后调用InnoDB存储引擎接口去读取记录。InnoDB对SELECT ... FOR UPDATE的加锁可以说比较直观：优化器会选择成本最低的索引路径访问，访问过程中对每条“扫描所见”的记录按需加锁。

关键点在于“扫描所见”四个字。比如你在user表上没有对age建索引，SQL是：

sql复制UPDATE user SET status = 2 WHERE age = 42;

由于没有索引，InnoDB只能对聚簇索引（主键索引）做全表扫描。InnoDB不会因为只命中一条age=42就直接只锁那一行，它会逐个索引记录地判断条件是否匹配，在这个判断过程中，已经给扫描到的多条记录加上了锁。也就是说，一个本来只改一条记录的SQL，也可能锁住大量其他记录。

这也是为什么我特别强调给WHERE条件建合适索引。不是为了查询性能本身，而是为了减少加锁覆盖范围。如果age上有二级索引，InnoDB会定位到二级索引中age=42的记录，对这个范围的索引记录加X锁，再回表对主键记录加X锁。锁的范围很小，其他不相关记录的更新不会被阻塞。

那二级索引加锁时为什么要同时给主键索引加锁？因为InnoDB的二级索引里并不存储完整数据，记录行本身的数据都挂在主键索引上。一个事务如果只锁二级索引而没锁主键，另一个事务就可以通过另一条二级索引或者主键条件找到同一行，绕开锁修改数据，这显然不行。所以InnoDB加行锁是“索引扫描路径上的锁 + 回表后主键记录上的锁”双重加锁。理解了这一点，你在看死锁日志时，看到同一条业务记录同时出现在两个索引的锁信息中，就不会觉得奇怪了。

3.2 隐式锁：为什么不在一开始就给每条插入记录加显式锁

如果你在事务里执行一条INSERT，然后用死锁日志的视角去看最新插入的记录，你会发现它有时并没有立刻生成一个正式的行锁对象。这是因为InnoDB有一条重要的优化：在某些场景下，锁可以“隐式”存在，靠记录头里的事务id字段来判别。

新插入一条记录时，记录头里会写入当前事务的trx_id。此时如果其他事务想更新或删除这条记录，它会根据记录头上的trx_id去事务系统里检查，发现这个事务还没有提交且持有写锁权限，就直接等在trx_id对应的事务上。这种“锁不是显式锁对象，而是通过记录上的事务id体现出来”的机制，就叫隐式锁。

Recovery之后或者事务提交时，隐式锁会转成显式锁，或者随着事务提交直接释放。为什么这样设计？因为INSERT阶段通常不会与其他事务冲突，两条INSERT只要不是插入同一个唯一键值，完全可以并发执行。如果每插入一条记录就在内存中创建一个锁结构，批量导入时会耗费大量内存，得不偿失。由于有trx_id这个天然标记，InnoDB就可以把真正创建锁对象的时机推迟到发生竞争的那一刻，节省资源。

理解隐式锁有助于你明白一个现象：INSERT并发虽然没有额外的行锁对象，但性能和阻塞不一定就少。如果插入了同一条唯一键冲突，后插入的事务会检查到前一事务的trx_id还活跃，就必须等待，这个等待同样会体现在事务等待图上。隐式锁是“用事务id充当锁信息”，不是“完全不上锁”。

3.3 锁结构：用位图把多条记录“打包”在一起

在InnoDB内存中，真正管理行级锁的对象是锁结构（lock_t）。每个锁结构可以包含多个记录，这涉及一个非常有实操价值的细节：InnoDB不是每锁一条记录就创建一个锁对象，而是把同一事务、同一索引、同一页类型、锁模式相同的记录记录在一个锁结构里，内部通过位图（bitmap）来标记哪条记录被锁了。

可以这样想象：锁结构是整个页面的一本台账，里面有一个位图，每个bit对应当前页面里的一个记录堆位置。事务要加锁时，如果发现页面上已经有同事务、同模式的锁结构，就直接把对应记录的bit置为1；如果某个页面是第一次加锁，就新建一个锁结构。

这套位图机制的收益是省内存。一个事务如果对一张大表批量更新数万行，这些记录可能分布在几十个页面里，InnoDB会把这数万条记录的锁压缩成数十个锁结构。否则，一个批量任务可能产生数以万计的锁对象，内存开销和锁管理成本都会失控。

同时，这里也牵出一个实践中的坎儿：大量行锁即使压缩在少量锁结构中，也会带来事务系统的压力。在长事务里批量UPDATE百万行，锁的锁结构本身不算多，但被锁的记录数仍可能触发锁等待风暴。你不能单纯依赖“锁结构压缩”就肆无忌惮地开大事务，commit的节奏依然要控制。

3.4 两阶段锁协议与 COMMIT 释放时机

InnoDB的锁释放遵循两阶段锁协议（2PL），简单说就是“加锁和释放锁分两个阶段，事务执行过程中只能不断加锁，不能提前释放；直到事务提交或回滚，所有锁才统一释放”。

这对业务的启示非常大。假设一个事务里先执行一条UPDATE，又需要读取刚才修改前的值做校验，你会随手再执行一条SLEEP或干等外部响应，此时这个事务持有的SQL已经执行完毕但事务未提交。由于2PL的限制，这些X锁不会在语句结束时释放，而是一直持有到COMMIT或ROLLBACK，期间所有后来事务访问同一行都会阻塞。

线上高并发场景常见的一种锁风暴就是慢查询造成的。一条UPDATE因为数据量大或没走索引执行了十几秒，它加上的行锁就白白占着十几秒，其他要更新这些行的会话全部排队。主库的连接数很快被打满，进而拖垮整个实例。解决思路不光是优化SQL，还要让单事务里锁的持有时间尽可能短。

提示：InnoDB不会在执行完一条DML后自动释放已加的行锁。所谓“autocommit=1”能减轻锁压力，是因为每条语句都自动提交了事务，锁在提交时一并释放。如果显式BEGIN后忘记COMMIT，哪怕只是发了三条SELECT ... FOR UPDATE，这些锁也会一直不释放，直到事务超时被系统回滚或者手动COMMIT。

4. 死锁产生、检测与日志解读

死锁是数据库并发里最让开发者头疼的问题。比起锁等待超时，死锁的特点在于它不会被无限等待吞掉，而是用“事务回滚”换来系统的继续前进。看完INNODB死锁日志后，很多人会疑惑：日志里明明只看到一条锁等待，怎么会形成死锁？答案通常在于，死锁发生时有一个事务持有的锁已经在另一个事务的等待链上，只是日志输出为了展现冲突核心，省略了部分上游信息。

4.1 死锁的成因与MySQL的等待图检测

死锁的经典条件是四个：互斥、持有并等待、不可剥夺、循环等待。数据库里最典型的场景是多个事务以不同顺序访问多行数据。事务A先锁行1再请求行2，事务B先锁行2再请求行1，两边都持有对方想要的锁且谁都不肯释放，就形成了环。

InnoDB在事务开始加锁等待时，会启动死锁检测机制。它会基于事务之间的等待关系构造一张等待图，图的节点是事务，边表示“一个事务在等待另一个事务持有的锁”。一旦发现图中出现回路，InnoDB就判定死锁发生，并选择回滚undo日志量较小（也就是修改量较少）的事务作为牺牲者，释放它的锁，让另一个事务继续执行。

死锁检测是默认开启的，参数叫innodb_deadlock_detect。这个检测过程不是免费的，它在高并发场景下会消耗CPU。如果系统并发量极大，且大量会话都在等待同一条热点记录，死锁检测反复扫描等待图的开销会非常明显。针对热点行更新严重的场景，有人会关掉死锁检测，完全依靠锁等待超时参数innodb_lock_wait_timeout兜底。

但我不建议轻易关掉死锁检测。关闭之后，死锁不会立刻报错，而是会演变成长达几十秒的锁等待，直到超时。超时本身也是阻塞，而且比死锁回滚伤害更大。关检测只在明确知道业务并发模型不会形成环时才是安全的，比如所有事务都按同一个顺序加锁，且冲突极低。

4.2 死锁日志里最重要的几行怎么读

当死锁发生时，InnoDB会将死锁信息记录到错误日志中。执行下面的SQL可以查看最近一次死锁的详细日志：

sql复制SHOW ENGINE INNODB STATUS\G

输出里有一个“LATEST DETECTED DEADLOCK”段落，通常包含两个事务的编号、执行的SQL和等待锁的信息。下面是一段简化的典型日志：

code复制2025-03-02 14:33:16 0x7f1c5b1b2700
*** (1) TRANSACTION:
TRANSACTION 821958, ACTIVE 12 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 981234, OS thread handle 139812348568320, query id 883911 10.2.3.4 app
UPDATE `trade`.`t_order` SET `status` = 2 WHERE `order_no` = '202503021234'

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 42 page no 15 n bits 96 index idx_order_no of table `trade`.`t_order` trx id 821958 lock_mode X locks rec but not gap waiting
Record lock, heap no 7 PHYSICAL RECORD: ...

日志里最关键的三段线索分别是：

• TRANSACTION开头会告诉我们这是一个事务，后面是事务id；
• LOCK WAIT和WAITING FOR THIS LOCK描述它正在等哪种锁；
• 后面紧跟的RECORD LOCKS描述等待的锁对象类型和索引名，lock_mode X说明等的是排他锁，locks rec but not gap说明这个锁只是记录锁，没有间隙锁。

如果你看到“lock_mode X locks gap before rec”，说明等待的是间隙锁或者临键锁，这类等待在范围更新里非常常见。看完第(1)个事务，继续往下看第(2)个事务，重点看它是否反过来持有了第(1)个事务需要的锁。只要日志里形成“事务1等事务2持有的锁，事务2又在等事务1持有的锁”，就能确定是循环等待造成的死锁。

在实际排查中，我不会只依赖死锁日志，还需要结合应用的调用链去判断两个事务各自的完整加锁顺序。死锁日志显示的只是发生死锁时刻的片段，同一个事务在这之前可能已经锁了另一张表的多条记录。只有把两条事务的完整SQL执行序列都还原出来，才能找到根因。

顺便说一个管理好习惯：建议开启MySQL 8.0的独立死锁日志表（events_errors_summary_by_thread_by_error），或者定期抓取SHOW ENGINE INNODB STATUS输出到专门的分析平台，方便回溯历史死锁，而不是只能看到“最近一次”。小型项目手动查可以接受，生产环境建议有日志归档机制。

4.3 从真实业务场景看典型死锁

下面这个场景非常典型：账务系统需要做转账，事务A给订单1001减金额，再给订单2002加金额；事务B则正好反过来。两条事务并发执行时就容易踩中死锁。

sql复制-- 事务A
BEGIN;
UPDATE orders SET amount = amount - 100 WHERE order_id = 1001;
-- 此时事务B可能正好持有order_id=2002的锁
UPDATE orders SET amount = amount + 100 WHERE order_id = 2002;
COMMIT;

-- 事务B
BEGIN;
UPDATE orders SET amount = amount - 100 WHERE order_id = 2002;
UPDATE orders SET amount = amount + 100 WHERE order_id = 1001;
COMMIT;

执行顺序只要出现：事务A锁了1001准备等2002，事务B锁了2002准备等1001，死锁立刻发生。解决方式一般是给所有涉及的资金流转操作定义一个统一的加锁顺序，比如每次同时操作两个订单时，都先按order_id排序，再从小到大更新。或者直接对两个订单一次性加锁：

sql复制SELECT id FROM orders WHERE order_id IN (1001, 2002) ORDER BY order_id FOR UPDATE;

这样两个事务获取锁的顺序完全一致，就不会出现循环等待。这里的核心不是“减少锁”，而是让并发事务的加锁路径变成同一条“单向车道”。

另一个常被忽略的死锁来源是先查后写模式。比如一个事务先执行普通SELECT查询用户余额，然后在业务代码里判断余额后执行UPDATE。如果两个事务同时读到相同余额，再各自按判断做扣减，虽然WHERE语句可能会因行锁排队而串行化，但业务里如果更新了关联的多张表，就容易形成跨表锁顺序不一。这种死锁不总是发生在同一条记录上，而往往是“A表某行 + B表某行”的组合循环。排查时看到死锁日志里的表名不止一张，就要立刻关注应用代码里的锁顺序是不是一致。

5. 锁等待与死锁的排查、优化清单

最后把实操层面的东西整合一下。这里不做长篇理论分析，给你一套能直接照着用的排查路径和优化方法。

5.1 用系统视图定位锁等待和阻塞源头

当业务反馈某个更新操作卡住时，第一步是先确认是不是锁等待。InnoDB提供了多个视图，最常用的有MySQL 5.7里的information_schema.innodb_trx、sys.innodb_lock_waits，在一些版本还会看到information_schema.innodb_locks。到了MySQL 8.0，部分锁视图被performance_schema.data_locks和data_lock_waits取代，但sys库的innodb_lock_waits仍然好使。

排查思路大概如下：

sql复制-- 1. 看当前所有未提交事务
SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id, trx_query
FROM information_schema.innodb_trx\G

-- 2. 直接查谁阻塞了谁
SELECT * FROM sys.innodb_lock_waits\G

sys.innodb_lock_waits会直接输出waiting_pid、waiting_query、blocking_pid、blocking_query等字段，比手动join多个视图直观得多。看到blocking_pid后，去查对应线程正在执行的SQL和事务持续时间，就能快速判断它是一个正在跑的长事务，还是一个忘记提交的僵尸事务。

如果blocking_pid对应的SQL已经执行完，但trx_started显示事务开启时间是几分钟前，那基本可以断定是应用层事务忘了COMMIT。此时最快速的恢复手段是KILL掉对应线程，让事务回滚并释放锁。执行：

sql复制SHOW PROCESSLIST;
KILL <thread_id>;

注意：KILL会话会导致事务回滚，可能影响正在执行业务的调用方。操作前需要确认这个会话可以被安全终止，最好是在业务低峰期并由有权限的DBA执行。

5.2 线上优化的核心手段

先说最有效、成本最低的一招：为WHERE条件加上合适的索引。之前提到过，没有索引的UPDATE会做聚簇索引全表扫描，加锁范围可能覆盖大量无关记录。有一次我排查一个支付流水表的更新堵塞，发现业务SQL是UPDATE pay_log SET retry_count = retry_count + 1 WHERE merchant_id = ? AND order_no = ?，但表上只有主键索引。结果这条UPDATE锁住了表内很大一片主键范围的记录，别的商户更新全被卡住。加上联合索引(merchant_id, order_no)后，锁范围锐减到两条记录，问题立竿见影。

第二个方向是把大事务拆成小事务。虽然“大事务”经常被看作回滚日志膨胀、锁持有时间长的根源，但拆分时要注意批量操作的节奏。比如一次任务要更新一万条记录，分批次每批处理200条并提交，单批锁持有时间就能控制在毫秒级。如果批次间还需要校验事务一致性，就得结合业务判断能不能接受部分成功。

第三个方向是重试机制。死锁和锁等待在并发系统里无法百分百避免，应用层应该把它们当成一种可预期异常。对死锁报错（错误码1213）和锁等待超时（错误码1205）做重试，但重试次数不要无限，建议设定2到3次，并在重试之间加入短暂延迟。重试前最好把事务整体回滚，重新开启新事务处理，而不是在旧事务内继续执行。

第四个手段是调整隔离级别和锁相关参数。如果业务确实不需要可重复读，把全局/会话隔离级别调整为READ COMMITTED能减少Gap Lock带来的冲突。但在做主从复制时要确认binlog_format为ROW，避免主库和从库执行结果不一致。

还有一个偏向业务设计的技巧是拆分热点行。典型case是秒杀场景里的商品库存。所有请求都在同一行上做库存扣减，即使行锁机制本身没问题，也会因为单点竞争把并发吞吐锁死。更优方案是把库存拆到多个子库存记录上，比如10个库存桶，每次扣减先随机或按用户hash选桶，再将扣减结果汇总。牺牲一点查询复杂度换取并发度，在高写入场景下收益非常明显。

5.3 锁相关参数速查与维护动作

把经常会被问到或容易踩坑的参数整理成一张速查表，方便你对照检查和设置。

维护动作上，建议形成一套日常巡检习惯。比如每天定时执行一次SHOW ENGINE INNODB STATUS并把结果归档，当系统报出死锁或锁等待时能回溯日志。每周从information_schema.innodb_trx里捞一次活跃时间超过阈值的事务，把长事务清单推给对应应用负责人去整改。

当一套系统已经踩过一次死锁坑之后，最好的办法是让开发规范跟上来。比如在代码评审中明确规定：涉及多行更新必须先排序后加锁；数据库写操作尽量放在事务最末尾完成；禁止在事务中执行RPC远程调用。这些规则看着简单，但能避掉绝大多数锁冲突问题。

我在实际排障过程中体会最深的一点，是不要被“锁”这个字吓住。InnoDB的锁虽然类型不少，但它的设计目标始终围绕两件事：保证事务隔离性，同时尽可能提高并发度。你只要能在脑子里把每个事务的加锁路径变成一张图，再判断两条路径是否有交叉，很多死锁和锁等待问题都能在写代码阶段就规避掉。MVCC帮你把读和写分开，锁又给了写与写之间的秩序，理解这一点后，再去看那些“标准答案”，你会发现里面全是活生生的生产经验和取舍逻辑。