MySQL锁机制详解：从行锁、间隙锁到死锁排查

1. 面试官问“MySQL锁机制”，究竟在考察什么

前两天有个读者私信我，说面试被问到“能讲讲MySQL的锁机制吗”，结果脑子一热就背了一段八股：有全局锁、表锁、行锁……然后就没有然后了。面试官点点头，又追问了一句“那MVCC和锁是什么关系”，直接卡住。复盘的时候他问我：这个问题到底要怎么答才算完整？

说实话，“MySQL锁机制”这个问题能在一分钟内讲完，也能讲半小时。面试官抛出这个题，其实不是在等你报菜名——把锁的类型一条条列出来当然重要，但真正想考察的是三件事：

第一，你有没有真正处理过并发场景。一个系统一旦流量上来，update、insert、delete同时打到同一行数据上，锁冲突、死锁、锁等待超时都是必然要面对的问题。有经验的人和没经验的人，讲出来的体感完全不同。

第二，你对MySQL的隔离级别、索引结构、事务机制是不是串起来了。锁不是孤立的知识点，它和InnoDB的索引B+树、MVCC版本链、redo/undo log全都纠缠在一起。能把锁讲清楚的人，通常意味着对整个InnoDB存储引擎有系统性的理解。

第三，你遇到问题会不会排查。线上出现锁等待，你是怎么定位的？是直接show processlist一把梭，还是会去查sys.innodb_lock_waits？同样的锁机制，背概念只需要十分钟，但排查问题的能力只能靠实际踩坑积累。

所以这篇文章我不打算只列概念，我尽量把锁机制放在真实场景里去讲，讲清楚它为什么存在、怎么工作、出问题怎么排，以及面试时怎么组织语言。文章使用的环境是MySQL 8.0（InnoDB引擎），这些知识对5.7同样适用，部分视图和参数名会有细微差别，我会单独标注。

2. 一个简单的select也会用到锁？从锁的实际触发时机说起

很多人对锁有个误解，觉得只有update、delete这种写操作才会加锁，select不加锁。这个说法对了一半——在默认的隔离级别下，普通的select走的是快照读，确实不需要加锁。但select有另一种形态叫当前读，它是要加锁的。我先把这个最基础的认知纠正过来。

2.1 快照读和当前读：无锁和有锁的分界线

快照读，就是普通的select查询，在InnoDB的MVCC机制下，读的是视图快照，不会对数据加任何锁，也不会阻塞其他事务的写入。这也是为什么在线业务系统里，大量查询可以和应用写入同时进行，互相不干扰。

当前读，则是指读取数据的最新版本，读的时候必须加锁，防止其他事务同时修改。例如下面的语句都属于当前读：

sql复制select * from t where id = 1 lock in share mode;   -- 加S锁（共享锁）
select * from t where id = 1 for update;           -- 加X锁（排他锁）
update t set name = 'a' where id = 1;              -- 先当前读，再加X锁
delete from t where id = 1;                        -- 先当前读，再加X锁
insert into t ...;                                 -- 加隐式锁

所以你看，update和delete执行时，第一步并不是直接改数据，而是先做一次当前读，把目标行锁住，再执行修改。这里就有一个很多开发者踩过的坑：一个update语句执行特别慢，不是因为它要改的数据量大，而是它在等锁——前面的某个事务已经把行锁住了，它只能干等。

我在实际项目中就遇到过，运营同事在后台批量更新一批订单状态，SQL写的是update orders set status = 2 where status = 1，结果这个语句一跑就卡住了。一查sys.innodb_lock_waits，发现是另一个正在跑的事务把相关行的排他锁拿在手里，批量更新只能等待。最后等了50秒，InnoDB的锁等待超时默认值是50秒，直接报错。

2.2 锁的粒度分类：从全局到单行

面试时讲锁的分类，建议按照粒度来分，层次更清晰：

• 全局锁：锁整个数据库实例，flush tables with read lock，做全库逻辑备份时才会用。
• 表级锁：锁整张表，包括表锁（lock tables命令）和元数据锁（MDL锁，对表结构做变更时触发）。
• 行级锁：用InnoDB实现，锁一行或者一个间隙，是并发场景下最精细、也最核心的锁。

三种粒度的锁，锁的范围从大到小，并发能力从小到大。InnoDB默认使用行级锁，但这并不意味着它没有表级锁——像DDL操作需要MDL锁，某些特殊场景下InnoDB甚至会自动升级成表锁（比如没有索引的update，或者全表扫描的当前读）。

这个特性极其重要，我多写两句。InnoDB的行锁是建立在索引上的，也就是说，行锁要锁的是索引记录，不是物理上的哪一行数据。SQL语句的执行计划如果通过索引定位到行，就锁索引记录；如果找不到索引、只能全表扫描，那InnoDB会对每一条扫描到的记录都加锁，相当于退化成了一张表锁。这是生产环境最容易被忽视的细节之一，明明表不大，一个不带索引条件的update就把整张表锁住了，后面的所有写操作全部堵塞。

3. InnoDB行锁的三种形态：Record Lock、Gap Lock、Next-Key Lock

把粒度讲清楚之后，下面要进入InnoDB锁机制最深、也是面试最容易深挖的部分：行级锁的三种形态。这部分如果只是死背名词，面试官往下追问一个“为什么需要间隙锁”，就会露馅。

3.1 Record Lock：记录锁，锁的是索引记录本身

Record Lock锁住的是索引中的一条具体记录。比如select * from t where id = 1 for update，如果id是主键，这条语句就只锁主键索引上id=1的那条记录。其他事务想update这条记录，需要等锁；想插入一条id=2的记录，不影响；想update id=3的记录，也不影响。

因此，Record Lock是行锁里粒度最小、并发能力最强的形态。它有两个模式：

• 共享锁（S锁）：事务读某行记录时加S锁，允许其他事务再加S锁读，但不允许其他事务加X锁写。
• 排他锁（X锁）：事务写某行记录时加X锁，不允许其他事务再加任何锁，读也不行。

这里有一个经典面试题：一个事务持有某行的S锁，另一个事务想对这行加X锁进行update，会发生什么？答案是等待，直到S锁释放。反过来，如果事务A先持有X锁，事务B想加S锁读，同样会等待。所以S锁和X锁是对立关系。

3.2 Gap Lock：间隙锁，用来治疗“幻读”

Gap Lock锁的是索引记录之间的间隙，是一个开区间，不包含记录本身。比如表中id有1、5、9三条记录，那么间隙就是(-∞,1)、(1,5)、(5,9)、(9,+∞)。Gap Lock会锁住某个间隙，禁止其他事务在这个间隙里插入新记录，但是它不锁记录本身。

为什么要锁间隙？为了防幻读。

举个例子。事务A在可重复读隔离级别下执行：

sql复制select * from t where id > 3 for update;

此时表里有id=1、5、9三条记录，所以事务A会把id=5和id=9两行锁住。但此时如果只锁这两行，事务B执行insert into t values(7)，插入一条id=7的新记录，事务A再次执行同一条查询，就会多出一行id=7的数据——这就是幻读。要防止这个情况，就必须把(5,9)这个间隙也锁住，禁止插入id在5和9之间的新记录，Gap Lock就是干这个的。

具体到上面这个语句，InnoDB会加以下锁：

• id=5和id=9的Record Lock
• (5,9)的Gap Lock

这样事务B插入id=7就必须等待，幻读被阻止了。

3.3 Next-Key Lock：间隙+记录的组合锁

Next-Key Lock是Gap Lock和Record Lock的组合，锁住一个左开右闭的区间。比如(5,9]就表示锁住id在5和9之间的间隙，同时锁住id=9这条记录本身。它的作用范围比Gap Lock大一点，防止在间隙中插入新记录，同时防止已有记录被修改。

在InnoDB的默认隔离级别可重复读（RR）下，当前读的加锁逻辑默认使用Next-Key Lock。这也是为什么很多MySQL优化经验里反复强调：尽量把隔离级别从RR改成读已提交（RC），因为RC只使用Record Lock，不会用Gap Lock和Next-Key Lock，锁的粒度更小、并发能力更高。MySQL默认使用RR，但Oracle默认是RC，从并发性能角度说，RC在多数业务场景下是更好的选择，代价是你需要自己处理一部分幻读风险。

需要强调一点：Gap Lock只在RR及以上的隔离级别下才启用，RC级别下InnoDB会禁用Gap Lock，只加Record Lock，这也是RC并发度更高的本质原因。

3.4 几个加锁场景的推演

我画不出流程图，但可以给你几个具体的SQL案例，自己照着这个逻辑推一遍，就通了。

前提表结构：

sql复制create table t (
  id int primary key,
  name varchar(20),
  age int,
  key idx_age (age)
) engine=innodb;

表中数据：id=1, name='a', age=10；id=5, name='b', age=30；id=9, name='c', age=50。

场景一：update t set name='x' where id = 5

这条语句走主键索引，锁定主键索引上id=5的记录，加一个X锁。什么间隙锁都不需要，因为主键唯一，不会产生幻读。

场景二：update t set name='x' where age = 30

这条语句走二级索引idx_age，先锁二级索引上age=30的记录，再回表锁主键索引上id=5的记录。由于age不是唯一索引，InnoDB在RR下会对二级索引的间隙加锁：age=10和age=30之间的间隙、age=30和age=50之间的间隙，都会被锁定。这就是普通索引当前读的加锁范围比较大的原因。

场景三：delete from t where name = 'a'

name列没有索引，这条语句会全表扫描。在RR下，它会对扫描到的所有记录加Next-Key Lock，等于把整张表的所有间隙和所有记录都锁了一遍。这就是我前面说的，没有索引的update/delete会把表锁住的原理。

4. 锁和事务隔离级别：从“锁什么时候加”到“锁什么时候释放”

面试时问完锁的类型，大概率会问：锁是什么时候加、什么时候释放的？这个问题对理解事务隔离级别至关重要。简单说：加锁的时机取决于SQL语句本身，释放锁的时机取决于事务提交或回滚。

4.1 事务边界决定锁的生命周期

InnoDB的默认锁策略是：在事务执行过程中加锁，事务提交或回滚时统一释放锁。这个特性给事务隔离级别提供了底层支撑。

举个例子。事务A执行：

sql复制begin;
update t set name='x' where id = 1;
-- 此时id=1的X锁在这个事务里
-- 在commit之前，其他事务无法修改这一行
commit;

如果事务A一直不提交，那id=1这行的X锁就一直持有，其他所有想修改这一行的事务全部会被阻塞，直到InnoDB的锁等待超时（innodb_lock_wait_timeout，默认50秒）报错。这也是为什么线上经常出现“一条update执行了50秒然后报lock wait timeout exceeded”的原因——不是SQL慢，是等锁等超时了。

很多时候不是SQL写得有问题，而是事务没有及时提交，锁被别人持有，时间越长，阻塞面越大。我在做数据库优化时，见到过很多因为“事务里查询太多、处理时间太长”导致锁长时间不释放的案例。

4.2 四类隔离级别下，锁用得完全不同

MySQL的四种隔离级别，每一种都和锁的使用方式强相关：

面试时最容易混淆的是“可重复读”和“读已提交”在锁上的差别：

在读已提交下，普通select走的是快照读，每次语句执行时都会生成一个新的快照，所以同一个事务里两次select可能读到不同版本的数据。加锁的当前读只加Record Lock，不加Gap Lock，所以并发能力高，但可能发生幻读。

在可重复读下，普通select走的是快照读，事务第一次select时生成快照，之后同一个事务里所有select都用这个快照，保证可重复读。加锁的当前读除了Record Lock还会加Gap Lock，从而在“当前读”的维度上也限制了幻读。

4.3 MVCC和锁到底怎么分工

这是一个高阶考点。MVCC和锁不是平行的两种机制，它们解决的是不同层面的问题：

• MVCC（多版本并发控制）负责处理“快照读”的并发。它通过undo log保存数据的历史版本，让读事务可以看见自己启动时的数据版本，从而实现读写不互斥。也就是说，普通select永远不会因为其他事务的写入而被阻塞。
• 锁负责处理“当前读”的并发和写入之间的互斥。update、delete、select for update这类语句必须读取最新版本的数据，不能走历史版本，所以必须加锁来保证当前读的结果是正确且唯一的。

两者搭配的结果就是InnoDB没有读写互斥的问题：一个事务在读历史版本，另一个事务在写最新版本，互不干扰。这也是MySQL能支撑高并发读写混合场景的核心原因。如果面试能把这条逻辑讲清楚，说明你真正打通了InnoDB的并发控制机制。

5. 死锁：线上最让人头疼的锁问题

讲完锁机制的基本原理，必须讲死锁。因为线上系统只要并发稍微上来，死锁是大概率会遇到的，这也是面试官非常喜欢延伸的问题。

5.1 死锁的四个必要条件

死锁指的是两个或多个事务相互持有对方需要的锁，形成循环等待，谁也无法继续执行。它的发生需要四个条件：

1. 互斥条件：一个资源只能被一个事务独占。
2. 请求与保持条件：事务已经持有一个资源，又去请求另一个资源，而该资源被其他事务持有。
3. 不可剥夺条件：事务持有的资源不能被强制剥夺，只能由持有者主动释放。
4. 循环等待条件：多个事务之间形成一个等待环路，比如A等B、B等A。

InnoDB检测到死锁之后，不会傻等，它会立即选择一个事务作为牺牲品，回滚它，释放它持有的锁，让其他事务继续执行。你用show engine innodb status查看锁信息时，能看到的LATEST DETECTED DEADLOCK就是这部分的记录。

5.2 一个真实死锁案例

我曾经在业务系统里遇到过一个典型的死锁：

sql复制-- 事务A
begin;
update account set balance = balance - 100 where id = 1;
update account set balance = balance + 100 where id = 2;
commit;

-- 事务B
begin;
update account set balance = balance - 100 where id = 2;
update account set balance = balance + 100 where id = 1;
commit;

当两个事务并发执行时，如果事务A先锁定了id=1，事务B同时锁定了id=2，然后事务A继续请求id=2的锁，事务B继续请求id=1的锁，就会形成循环等待。InnoDB检测到死锁后，选择回滚其中一个事务，报错信息大致是Deadlock found when trying to get lock; try restarting transaction。

这个案例在转账、库存扣减、订单状态流转等场景里非常常见，核心原因是两个事务以不同的顺序访问了同两张表或同一组数据。

5.3 死锁的定位手段

一旦出现死锁，不要慌，第一步是把死锁日志拿出来：

sql复制show engine innodb status\G

看LATEST DETECTED DEADLOCK段，里面会记录两个事务的SQL语句、持有和等待的锁、回滚了哪个事务。

但有个问题：show engine innodb status只能看到最近一次死锁的信息，如果死锁频繁发生，这个输出已经不准确了。此时需要开启死锁日志记录：

ini复制innodb_print_all_deadlocks = ON

打开这个参数后，每次死锁都会记录到MySQL错误日志中，方便复盘。

更重要的是通过代码层面规避死锁，我总结了几条很实用的经验：

• 尽量以固定顺序访问表和行，比如所有事务都按id升序更新记录，破坏循环等待条件。
• 缩小事务范围，减少锁的持有时间。一个事务里不要塞太多无关查询，写完就提交。
• 合理设计索引，避免全表扫描时对所有记录加锁，扩大锁范围。
• 使用读已提交隔离级别，减少Gap Lock导致的不必要锁冲突。

5.4 死锁和锁等待超时的区分

很多开发者把死锁和锁等待超时混为一谈，其实两者完全不同，排查方向也不一样。

死锁是InnoDB检测到循环等待，主动回滚一个事务，报错是Deadlock found，业务代码里捕获到异常后通常重试即可。锁等待超时则是一个事务在等另一个事务释放锁，等的过程中就超过了innodb_lock_wait_timeout（默认50秒），报错是Lock wait timeout exceeded，它不一定是死锁，可能是更常见的锁竞争问题，即某个事务持有锁时间过长，或者持锁事务一直没有提交。

定位锁等待问题，我用的最多的是这几条SQL：

sql复制-- 查看当前所有事务
select * from information_schema.innodb_trx\G

-- 查看当前所有锁
select * from information_schema.innodb_locks;
-- 8.0版本改用
select * from performance_schema.data_locks;

-- 查看锁等待关系
select * from information_schema.innodb_lock_waits;

innodb_trx里能直接看到每个事务的状态、锁等待时间、事务开始时间，重点看trx_state是RUNNING还是LOCK WAIT，以及trx_started是什么时候开的——如果是好几秒前开的且状态是LOCK WAIT，基本可以判断锁等待问题出在这条SQL前面的某个事务一直没提交。

6. 锁机制的面试回答模板与避坑技巧

最后说说面试怎么答。毕竟这个标题是“面试真题”，虽然我们的核心目标是理解原理，但把理解转化成面试话术也很重要，毕竟面试有时间限制，总不能讲半小时还没讲到重点。

6.1 面试时按这个结构来答

我建议按“是什么—为什么—怎么办”的结构回答，控制在3~5分钟：

1. 先点明锁是InnoDB实现并发控制的核心机制，结合隔离级别解决并发一致性问题。
2. 按粒度讲锁的分类：全局锁、表锁、行锁，重点介绍行锁的Record Lock、Gap Lock、Next-Key Lock，并说明锁是加在索引上的，不是加在记录上的。
3. 讲MVCC和锁的协作关系：MVCC解决快照读的隔离，锁解决当前读的并发控制，二者结合实现读写互不阻塞。
4. 提一句真实场景：比如一条不带索引的update为什么会锁表，两个事务以不同顺序更新为什么产生死锁。
5. 如果面试官追问题，回答时保持冷静，宁可说“这块我遇到过、思路是这样”去展示实战经验，也不要背完概念就停。

避免犯的错：不要只说“锁分共享锁和排他锁然后就没了”，这是最浅层的回答；不要一上来就答死锁，死锁是扩展题，不是主线。

6.2 实战经验补充：锁问题排查的完整流程

如果面试官问你线上遇到锁问题怎么排查，你可以把下面这条流程讲出来，这是一套完整的思路：

第一步，发现症状。表现通常是应用报Lock wait timeout exceeded，或者接口响应变慢、数据库CPU狂飙。

第二步，定位事务。查information_schema.innodb_trx，找出状态为LOCK WAIT的事务和它的trx_query，同时找到持有锁的那个事务。持有锁的事务的trx_state可能是RUNNING，需要重点看它的trx_started时间，判断它持锁多久了。

第三步，分析锁关系。查sys.innodb_lock_waits视图，这个视图直接关联了等待事务和阻塞事务的信息，输出里包含waiting_pid、blocking_pid，一眼就能定位是谁堵了谁。

第四步，处理。如果阻塞事务确实不活跃，可以kill掉阻塞事务的线程ID；如果是代码问题，那就从源头优化事务逻辑。

第五步，预防。通过合理索引、缩短事务、统一加锁顺序、必要时调整隔离级别来减少锁冲突。

这条流程在面试里讲出来，面试官基本不会再深问，因为它证明你确实处理过问题，而不是只停留在理论层面。

6.3 再补充几个小技巧

• 所有加锁语句都尽量在事务最前面执行。事务启动后，把最需要持锁的操作放到最前，缩短持锁时间，后面其他操作就不容易和锁冲突。
• 批量update/delete语句，尽量拆成小批次执行。比如一次更新1万行和一次更新100行，锁的持有范围和持有时间天差地别。
• 尽量保证SQL走索引。这是老生常谈，但对锁机制来说意义更重大：走索引用的是行锁，不走索引用的是表锁级别的全表锁，并发能力完全不是一个量级。
• 读多写少的场景，可以考虑把隔离级别改成RC。RC的行锁不包含Gap Lock，锁冲突概率大幅下降，如果业务可以接受RC级别下潜在的不一致，性价比极高。

在我自己的项目里，遇到高并发写场景，我通常会把RC隔离级别作为首选，只有当业务确实需要可重复读时才维持默认的RR。这一点在做系统设计时值得好好权衡。

锁机制讲到这里，核心的东西基本都覆盖了。概念、原理、案例、排查流程，该有的都有了。面试的时候真正拉开差距的，不是谁能多背一个名词，而是谁能把“为什么”讲明白——为什么锁加在索引上、为什么要有间隙锁、为什么MVCC还不够、死锁为什么只能通过设计来尽量避免，这些链条能串起来，才算是真正吃透了MySQL的锁机制。