1. 从一次线上锁等待排查说起：MySQL锁到底锁住了什么
先说一个我真实处理过的线上问题，它让我彻底把MySQL锁机制重新认真过了一遍。
某个晚上，业务方突然反馈说接口超时严重，紧接着监控平台刷出一堆报错：Lock wait timeout exceeded; try restarting transaction。登录数据库后，我用一条查询看到几十个会话都卡在同一个状态上：
SELECT * FROM information_schema.innodb_trx\G排查下来，根源是一个同事手动执行了一条大范围的UPDATE，一次性更新了好几万行，而且这条语句只用了索引前缀，没有完全走唯一索引，导致它拿住的锁范围远超预期。后面所有涉及这张表的写入请求都排到了它后面，等到innodb_lock_wait_timeout（默认50秒）一到，就集体报错。
这就是锁在最真实场景里的样子。为了定位这类问题，你必须先搞清楚一个基本问题：MySQL 到底有哪些锁，每一把锁分别锁住了什么、什么时候生效、什么时候释放。
这篇文章我不会按照官方文档的方式平铺直叙，而是从实际使用和排查的视角，把我认为最值得梳理的锁分类框架、每类锁的具体行为，以及线上排查经验一次性讲清楚。不管你是后端开发、业务架构师还是专职DBA，只要你的系统里跑的是MySQL InnoDB，这部分迟早要用到。
2. 先搭框架：粒度、模式、实现三条线看懂锁分类
很多讲锁的资料一上来就列满各种种类，容易看懵。其实可以换成三个维度来理解：粒度、模式、实现机制。掌握了这三条线，后面所有具体锁的名字都可以归位。
2.1 按粒度分：全局锁、表级锁、行级锁
粒度说的是锁作用范围的大小，由大到小排列是：
- 全局锁：作用在整个数据库实例上，一个实例同时只能有一把全局锁。
- 表级锁：作用在一张表上，直接限制这张表的所有记录。
- 行级锁：作用在索引记录层面，是InnoDB最有代表性的锁，也是并发性能的关键。
这个划分决定了并发度的根本差异：行级锁能让两个事务同时修改同一张表里不同的行，表级锁则做不到。所以 InnoDB 选择行级锁作为默认引擎，也是OLTP场景下并发能力的根基。
2.2 按模式分：共享锁、排他锁与意向锁
模式指的是锁的“读写属性”，它决定了两把锁碰在一起时是否冲突。
- 共享锁（S锁）：读锁，多个事务可以同时持有同一资源的S锁。
- 排他锁（X锁）：写锁，同一资源只能有一个事务持有X锁，其他S锁和X锁都会被挡在外面。
- 意向锁（IS / IX）：这是InnoDB特有的一种表级锁标记，它表示“这个事务准备在表里的某些行上获取S锁或X锁”，本身并不限制其他事务读数据，但用来和表级锁做快速冲突判断。
意向锁是很多人忽略的点，但它的作用很精巧。如果没有意向锁，当一个事务要锁整张表时，数据库必须去检查表里每一行是否有行锁，成本不可接受。有了意向锁，表级锁申请时只要看看表上有没有对应的意向锁就能立刻判断是否冲突。
2.3 按实现机制分：记录锁、间隙锁、临键锁
这是InnoDB在最底层真正存放的锁结构：
- Record Lock：只锁索引记录本身。
- Gap Lock：锁住索引记录之间的间隙，防止其他事务在间隙里插入记录。
- Next-Key Lock：记录锁和间隙锁的组合，锁住左开右闭区间，既锁记录也锁间隙。
日常口头上说的“行锁”，在 InnoDB 里绝大多数时候其实是 Next-Key Lock，而不是单纯的记录锁。这一点后面会展开说。
2.4 一张表看清锁的兼容性
把模式组合做出来，就是经典的锁兼容矩阵：
| 锁类型 | S（共享锁） | X（排他锁） | IS（意向共享） | IX（意向排他） |
|---|---|---|---|---|
| S | 兼容 | 冲突 | 兼容 | 冲突 |
| X | 冲突 | 冲突 | 冲突 | 冲突 |
| IS | 兼容 | 冲突 | 兼容 | 兼容 |
| IX | 冲突 | 冲突 | 兼容 | 兼容 |
记忆技巧很简单：X锁和谁都不兼容，意向锁之间互相兼容。实际使用中，普通SELECT不加任何锁，SELECT ... FOR UPDATE加X锁，SELECT ... LOCK IN SHARE MODE加S锁。
3. 表级锁的三员大将：显式表锁、MDL锁与自增锁
先说一个经常被误解的点：很多人以为 InnoDB 只有行级锁，其实它仍然有一层表级锁。表级锁在 InnoDB 体系里不是主角，但恰恰是线上故障的高发区。
3.1 显式表锁：InnoDB里的“非常规武器”
MySQL允许通过LOCK TABLES直接锁整张表：
LOCK TABLES user_table WRITE; -- 做一些需要整表独占的操作 UNLOCK TABLES;在 MyISAM 时代这是常规操作，因为 MyISAM 只有表锁。但在 InnoDB 下，显式表锁会直接绕过行锁机制，把整表的并发全部串行化，所以除非是批量迁移、冷备之类的特殊场景，我很少建议在生产环境主动用它。
另一个需要注意的是：LOCK TABLES会隐式提交当前事务。如果你正在一个长事务里，执行它之前一定要确认事务已经提交或回滚完成，否则数据一致性容易出问题。这也是为什么它只适合在专门的维护窗口用。
3.2 MDL锁：为什么加字段会卡住整张表的读写
MDL（Metadata Lock）是表级锁里最容易造成线上事故的一个。它的作用是保护表的元数据，比如表结构、字段定义，防止一个事务在读取表结构时，另一个事务把表结构改了。
规则是这样：
- DML（增删改查）执行前，要获取表的MDL读锁，多个事务可以同时持有读锁。
- DDL（改表结构）执行前，要获取表的MDL写锁，写锁和读锁、写锁之间都互斥。
所以，一旦有一个长事务迟迟不提交，它手里就一直握着MDL读锁。此时如果有人执行ALTER TABLE，这条DDL会在“等待MDL写锁”的状态下卡住。更麻烦的是，这个等待中的DDL本身又会阻塞后面所有新的DML请求，因为它们需要排队读锁且写锁优先级更高。
我见过一个典型的案例：开发同学下午四点发起了一个ALTER TABLE给大表加索引，执行超过半小时还没完成。一查，是因为有一个查询跑了二十分钟没结束，死死攥着MDL读锁。更糟的是，这半小时内所有新的读写请求全部堆在MDL队列里，整个业务的数据库操作基本瘫痪。
排查MDL问题，重点是看performance_schema.metadata_locks表，或者等锁现象出现后观察SHOW PROCESSLIST，能看到一堆Waiting for table metadata lock的会话。
3.3 自增锁：别小看auto_increment的并发策略
自增列写入时，InnoDB需要保证同一个表生成的自增值不重复，这里也涉及一把内部的表级锁——自增锁。它的实现受参数innodb_autoinc_lock_mode控制，这个参数有三种取值：
| 模式值 | 行为 | 适用场景 |
|---|---|---|
| 0 | 传统锁，INSERT语句执行期间持表级自增锁 | 兼容旧版 |
| 1 | 连续模式，普通INSERT按批量申请，但不确定数量的INSERT仍持锁 | MySQL 8.0之前的默认值 |
| 2 | 交错模式，只保证自增值唯一且递增趋势，不保证连续 | MySQL 8.0之后的默认值 |
模式2能明显提升高并发插入的性能，因为普通INSERT不再需要拿表级锁，只在最后生成自增值时用轻量互斥。但它带来的代价是：并发插入时，多个事务拿到的自增值可能有空洞，比如事务A拿到2，事务B拿到3，事务A回滚了，那么后续插入会出现2被跳过的情况。如果你业务上要求自增主键严格连续——大多数人其实没这个需求——那要谨慎用模式2。
自增锁的另一种表现为LOCK_TABLE等待，通常在批量导入大量数据时出现。线上如果发现INSERT语句卡在自增锁等待上，可以考虑调成模式2，或者检查是否有大事务长时间占用了自增资源。
4. 行级锁的纵深拆解：Record Lock、Gap Lock、Next-Key Lock
行级锁是InnoDB的看家本领，也是并发性能的保证。但行级锁内部并不只有“锁住一行”这么简单，它的细节直接决定了你在隔离级别下的行为和死锁概率。
4.1 Record Lock：锁的是索引记录，不是数据行
Record Lock 锁住的是索引记录。InnoDB的行锁是基于索引实现的，这句话很多人听过但没细想。
假设你执行：
SELECT * FROM user WHERE id = 100 FOR UPDATE;如果id是主键，那么InnoDB会在主键索引上找到id=100的那条记录，给它加X锁。但如果你的WHERE条件用的是普通字段，且这个字段上没有任何索引，那么InnoDB会走全表扫描，对整个表范围内的所有索引记录尝试加锁——这就是大范围更新把全表锁住的根本原因。
这也是为什么我一直强调：更新和删除操作的WHERE条件，一定要保证命中的目标行能被索引精准定位。不加索引看起来只是慢，实际上会让锁范围从几行膨胀到几十万行，直接拖垮并发。
4.2 Gap Lock：锁间隙是为了防“幻读”
Gap Lock 锁的是记录之间的“间隙”，注意这个间隙可能很大。
比如表里主键是1、5、10，那么在1和5、5和10之间，以及10之后到正无穷之间都存在间隙。在可重复读（RR）隔离级别下，事务A在WHERE id BETWEEN 3 AND 8的范围内加锁，它不仅要锁住5这一条记录，还要锁住(1,5)和(5,10)这些间隙，防止另一个事务在区间里插入主键为3、7这类新记录。
如果没有间隙锁，事务A第一次查询没有6这条记录，事务B插入6并提交，然后事务A再次查询居然看到了6，这就是幻读。InnoDB在RR下默认通过Next-Key Lock来彻底杜绝幻读。
注意：Gap Lock 只锁间隙，不锁记录本身，所以它和记录锁不是完全冲突。两个事务可能同时持有同一间隙的Gap Lock，因为它们都在防止别人插入，但不会互相阻塞，只有真正插入时才可能互相等待。
4.3 Next-Key Lock：记录锁加间隙锁的“组合拳”
Next-Key Lock是Record Lock和Gap Lock的组合，它锁住的是一个左开右闭的区间，比如(1,5]。它的作用是：既锁住5这条记录，又锁住1到5之间的间隙。正因为用了这个组合，才保证了RR隔离级别下不仅读不到其他事务未提交的记录，还能防止其他事务在范围内插入新数据。
在实际使用中，绝大多数UPDATE、DELETE在RR隔离级别下加的都不是Record Lock，而是Next-Key Lock。只有一种情况例外：当你的查询条件命中唯一索引且能精确定位到单个记录时，InnoDB会把锁降级为Record Lock，因为此时间隙锁没有意义——既然这条记录是唯一的，不可能再有别的记录插入到它旁边。
4.4 读已提交（RC）与可重复读（RR）的锁差异
RC和RR在锁行为上有本质差异，这也是为什么很多团队会纠结选哪种隔离级别。
| 隔离级别 | 默认搜索锁 | 是否使用Gap Lock | 是否防幻读 | 并发度 |
|---|---|---|---|---|
| RC | Record Lock | 基本不用 | 否 | 更高 |
| RR | Next-Key Lock | 默认使用 | 是 | 相对更低 |
RC下，InnoDB会把查询遇到的每一行都尝试加Record Lock，但不会锁间隙，所以另一个事务可以在“两个已存在记录之间”插入新数据。同时RC还有一个特殊机制叫“半一致性读”，当执行UPDATE并发现目标记录被其他事务锁住时，会先读该记录已提交的旧版本，判断它是否真的满足WHERE条件，如果不满足就直接跳过，避免不必要的锁等待。
从锁冲突概率来看，RC通常比RR更低。很多互联网公司会将数据库默认隔离级别改为RC，换取更高并发，代价是自己要在业务层处理一部分幻读问题。改不改，需要评估业务语义是否依赖RR的间隙锁来防止插入。
5. 全局锁的价值与代价：一致性备份场景下的取舍
全局锁在业务开发里很少主动用，但在备份、导入导出、维护场景下却非常关键，它的作用是保证整个实例在某个瞬间的数据是一致的。
5.1 FLUSH TABLES WITH READ LOCK
MySQL提供一行命令：
FLUSH TABLES WITH READ LOCK;执行后，整个实例进入只读状态，所有读写请求都会被阻塞。这能确保你在这个时间点拿到的备份，对应的是同一个事务一致性的快照，不会出现备份到一半时数据还在变的问题。
但它的问题也很明显：数据库只读意味着线上业务全部停摆。再加上如果备份期间某个长事务已经持有MDL锁，这条命令可能还会无穷等待。所以它更适合在从库、低峰期执行，不适合在核心业务库上直接裸用。
5.2 更轻量的替代方案
如果是InnoDB，其实有更好的选择：利用可重复读隔离级别下的一致性快照。比如用mysqldump加--single-transaction参数时，备份工具会在事务开始时建立一致性读视图，后续备份过程中，其他事务的写入不会影响备份内容，也就不需要FLUSH TABLES WITH READ LOCK来锁全库。
在被锁等待迷惑之前，先想想你要的到底是“结构一致”还是“数据一致”。数据一致且事务引擎是InnoDB时，优先考虑MVCC快照；只有涉及非事务表或需要精确停机窗口时才动用全局锁。备份这件事，10次里有9次是用快照而不是全局锁完成的。
6. 锁等待与死锁的实战排查：从视图到状态再到处理
聊完分类，说点最能直接拿来用的：线上遇到锁问题，应该按什么顺序排查。
6.1 第一步：查事务与锁等待视图
8.0以前的MySQL，最常用的排查入口是information_schema里的三张表：
SELECT * FROM information_schema.innodb_trx; -- 当前事务 SELECT * FROM information_schema.innodb_lock_waits; -- 锁等待关系 SELECT * FROM information_schema.innodb_locks; -- 当前锁信息8.0以后，推荐用performance_schema里更完整的表：
SELECT * FROM performance_schema.data_locks; SELECT * FROM performance_schema.data_lock_waits;这两张表能看到锁的引擎、类型、模式，以及锁定的索引记录范围。通过data_lock_waits里的BLOCKING_PROCESS和WAITING_PROCESS字段，能直接看出是谁在等谁。
排查思路是：先找到哪个事务的trx_state是 LOCK WAIT，再看它的trx_started是不是已经持续了好几分钟。如果发现某个事务启动时间很久，大概率就是元凶。
6.2 第二步：查看InnoDB引擎状态
视图能告诉你锁等在哪里，但要看死锁的具体SQL，还得靠：
SHOW ENGINE INNODB STATUS;输出内容里有LATEST DETECTED DEADLOCK一段，记录了最近一次死锁发生时两个事务的执行SQL、持有和等待的锁、回滚的是哪个事务。这些信息是后续优化SQL的直接依据。
6.3 一个我实际遇到的死锁案例
某活动系统里有一个账户余额明细表，业务代码的逻辑是：先查用户余额，再插入一条明细，再更新账户余额。高峰期并发高的时候，频繁出现死锁。
死锁日志简化后是：
- 事务A：
UPDATE account SET balance = balance - 100 WHERE uid = 1001; - 事务B：
UPDATE account SET balance = balance - 200 WHERE uid = 1001; - 两个事务都在等待对方释放同一行上的X锁，于是死锁。
这个案例看起来很简单，但实际业务代码里往往还包裹了其他表操作。例如事务A先更新明细表再更新账户表，事务B先更新账户表再更新明细表，形成交叉锁。解决方式有两个层面：
- 统一加锁顺序：所有事务都按“账户表→明细表”的顺序访问资源。
- 减少事务持有锁的时间：把无关查询和计算放到事务外，事务里只保留必要的更新语句。
6.4 处理锁问题时的三条经验
- 遇到锁等待超时，别急着杀线程。先确认等待者是不是被一个长事务拖住，如果是，找到源头事务，评估是否能快速提交或回滚。
- 用
KILL命令时要想清楚：杀掉的是持有锁的一方还是等待锁的一方。杀错对象，业务报错会扩大。 SHOW PROCESSLIST里的Time列可以用来快速定位长时间运行的会话，配合最新一次执行的SQL，能判断它是否持有过多锁。
7. 降低锁冲突的几条实操方法论
锁机制本身是数据库内部的事，但从开发侧可以主动避免大量锁冲突。我在日常代码评审里反复强调下面几点，效果最直接。
7.1 索引设计是“锁优化”的第一优先级
前面已经提过，InnoDB的锁是在索引记录上做的。一条UPDATE能不能精准锁行，取决于优化器是否使用了合适的索引。
看这个例子：
UPDATE order_table SET status = 1 WHERE user_id = 123;如果user_id有索引，锁的范围就是user_id为123的若干行。如果没索引，优化器可能全表扫描，这时InnoDB为了不产生脏数据，会对碰到的每一行都加锁，本质上就是把行锁升级成了“变相表锁”。所以，写SQL前先执行EXPLAIN，确认type不是ALL或明显的大范围索引扫描，是避免锁膨胀的第一步。
7.2 事务要短，锁要晚拿
锁是从事务内第一条加锁SQL开始持有的，直到事务提交或回滚才释放。一个事务里跑10秒无关查询，锁就默默攥10秒，在这10秒里任何写入到相同行的事务都得等。
所以业务代码的写法应该是：
- 把查询、远程调用、复杂计算放到事务开启之前。
- 事务里只放必须原子操作的DML。
- 尽早提交，拒绝“事务内等着用户输入”这种情况。
这条对所有数据库都适用，但在MySQL InnoDB下尤其重要，因为行锁的等待直接影响吞吐量上限。
7.3 一致的加锁顺序
多个事务同时更新多张表或多行数据时，尽量保证加锁顺序一致。比如先更新主表，再更新子表；或者统一按主键ID从小到大更新。这样可以将“循环等待”这个死锁条件从源头上断掉。
尤其注意批量更新列表时，如果处理顺序不一致，两个事务很容易互相持有对方下一步需要的锁，死锁概率翻倍。
7.4 参数调整要克制
innodb_lock_wait_timeout默认是50秒，有时业务希望更快报错而不是干等，可以适当调低到5~10秒，但别调得太低，否则正常的高峰排队也会变成超时。lock_wait_timeout是针对元数据锁的等待超时，默认值很大，改之前要评估DDL维护场景。
这两类超时参数，是“最后一道防线”而不是“优化手段”。根子上的问题还是要靠索引、事务设计去解。
7.5 善用只读查询减轻写锁压力
如果某类统计查询并不关心实时数据，可以用REPEATABLE READ下的事务快照来读取，或者在从库上执行分析任务，避免给主库的行锁队列增加压力。把读流量分流到从库，是降低主库锁冲突最简单有效的扩容手段。
写在最后的一段个人心得
做数据库排查这几年，我最大的感受是：死锁和锁等待看起来吓人，但只要手里有“锁分类”这张地图，定位问题的速度就完全不一样。第一步先判断是表级锁还是行级锁，表级锁优先查MDL和长事务，行级锁优先看执行计划选中的索引范围，然后顺着data_locks找到那个持有锁的旧事务，问题基本就浮出水面了。
还有一个习惯推荐给所有写业务SQL的同学：每次上线涉及UPDATE、DELETE的脚本，顺手用EXPLAIN看下索引命中情况。这一步花不了几秒钟，但能帮你省掉无数个被锁等待折腾的深夜。MySQL锁本身不是一个需要死记硬背的知识点，把它放到“索引命中范围”和“事务持有时间”这两个真实工作场景里去理解，你会很快就掌握它。
