1. 先从并发场景说起锁到底在解决什么问题做后端和数据库这行锁是绕不开的话题。很多人背了一堆概念知道 MySQL 有表锁、行锁也知道 MVCC 里有个临键锁但真到线上出问题——某个更新语句把整个表锁住了或者两个事务互相等对方释放锁最后直接死锁这时候才发现自己只懂概念、不会排查。这篇文章不打算照抄文档而是把表锁、行锁、MVCC 中使用的临键锁放到一条完整的线里讲清楚它们各自解决什么问题、底层怎么运作、线上怎么排查、有哪些坑。先说最根本的问题数据库为什么需要锁因为多个事务并发读写同一份数据时如果不做任何约束就会出现三类经典问题——脏读读到别人未提交的数据、不可重复读同一查询前后结果不一致、幻读同一查询前后行数不一致。锁就是通过互斥和阻塞让互相冲突的操作串行化从而保证事务的隔离性。而锁的粒度决定了并发能力表锁粒度大一个操作锁住整张表简单但并发低行锁粒度小只锁住需要操作的行并发高但管理和检测成本也更大。InnoDB 引擎之所以成为默认选择核心就是它同时支持行锁和 MVCC在保证隔离性的前提下把并发能力做得足够好。下面我们从最粗暴的表锁开始一层层往里拆。2. 表锁粒度的尽头简单但粗暴2.1 表锁的两种基本形态与兼容规则表锁是 MySQL 中最容易理解的一种锁它的思想很简单事务在操作表之前先给整张表加锁。MySQL 的表锁分为两种表级共享锁S 锁也叫读锁加了读锁之后其他事务可以继续加读锁但不能加写锁。表级独占锁X 锁也叫写锁加了写锁之后其他事务无论是加读锁还是加写锁都会被阻塞。用一张矩阵就可以说清兼容性锁类型共享锁S独占锁X共享锁S兼容冲突独占锁X冲突冲突也就是说读读不阻塞读写阻塞写写阻塞。这背后的逻辑很直接多个事务同时读同一张表彼此不会破坏数据一致性但只要有一个事务在写其他读写都必须等否则就可能读到写了一半的数据或者两个写操作互相覆盖。表锁的优点是开销小、实现简单、没有死锁检测的负担缺点是粒度太粗任何写入操作都会阻塞这张表上所有的读写操作并发性能非常差。在需要频繁写入的业务表上使用表锁基本等于把并发能力砍到零只适合读多写极少或者批量一次性操作的特殊场景。2.2 显式表锁的正确姿势与常见误区手动加表锁使用LOCK TABLES语句。比如我要单独锁一张用户表-- 给 users 表加读锁 LOCK TABLES users READ; -- 给 users 表加写锁 LOCK TABLES users WRITE; -- 释放当前会话持有的所有表锁 UNLOCK TABLES;实操中有几个点特别容易踩坑。第一LOCK TABLES是会话级的不是事务级的它需要在事务之外显式执行并且一旦执行了LOCK TABLES当前会话默认会自动提交尚未完成的事务然后才能加锁。第二锁表期间只能访问显式加锁的表。如果你同时锁了users和orders两张表那么在解锁之前访问第三张表会直接报错必须把所有要用的表一次性全部锁上LOCK TABLES users WRITE, orders WRITE;第三点是很多新手忽略的在 InnoDB 的默认场景下业务代码里几乎不需要手动LOCK TABLES因为行锁已经能做到更精细的并发控制。手动加表锁通常只出现在两种场景需要对某张表做一次性迁移、清理、备份且不希望有任何写入打扰或者使用的是 MyISAM 引擎MyISAM 只有表锁没有行锁能力。如果你在 InnoDB 表上习惯性用LOCK TABLES实际上是自废武功把 InnoDB 的行锁优势完全丢掉了。2.3 容易被忽略的两张“隐形表锁”除了显式LOCK TABLESInnoDB 里还有两种表级别的锁虽然不会频繁出现在业务代码里但线上问题往往由它们引起。第一是MDL 锁元数据锁。从 MySQL 5.5 开始引入它的作用是保护表结构定义。任何一条 SQL 在执行时都会先获取目标表的 MDL 读锁DDL 操作比如ALTER TABLE需要获取 MDL 写锁。如果有一个长事务长时间不提交一直占着某张表的 MDL 读锁后面的ALTER TABLE就迟迟拿不到写锁更麻烦的是DDL 一旦在排队等待它后面所有对这个表的新查询都会被 MDL 队列阻塞表现为这张表突然所有读写都卡住了。这种问题在线上非常常见排查时记得要去看performance_schema.metadata_locks或sys.schema_table_lock_waits定位到那个持锁的长事务后 kill 掉通常能立刻恢复。第二是AUTO-INC 锁它是处理自增主键插入时的特殊表级锁。在旧版 MySQL 中向带自增列的表插入数据时必须先拿到 AUTO-INC 锁以保证自增值严格连续且不重复代价是同一时刻只能有一个事务执行插入。好在新版本通过innodb_autoinc_lock_mode参数做了优化推荐值 2即交错模式插入语句不再需要互斥整个表大幅提升了高并发插入场景的吞吐量。但如果你在代码里显式指定了自增列的固定值或者使用INSERT ... ON DUPLICATE KEY UPDATE仍然可能触发特殊加锁路径这点做高并发写入优化时要心里有数。3. 行锁InnoDB 的精细活3.1 行锁的三件套Record Lock、Gap Lock、Next-Key LockInnoDB 的行锁并不是简单地在一行上做互斥它实际上有三种形态这也是理解临键锁的前提Record Lock记录锁只锁索引上的某一条具体记录。比如SELECT * FROM users WHERE id 5 FOR UPDATE命中唯一索引 id5 时只给这一条记录加锁。Gap Lock间隙锁锁住一个开区间范围比如索引值 4 和 8 之间存在(4, 8)这个间隙间隙锁会禁止其他事务在这个间隙里插入新记录但不会锁住已有的记录本身。Next-Key Lock临键锁可以理解为前两者的组合同时锁住一条记录以及它前面的间隙作用范围是一个左开右闭区间(a, b]。临键锁既锁住了已存在的记录又防止了新的记录在前面的间隙中插入。三者的核心区别可以用一个简单例子说明。假设一张表的索引列有 10、20、30 三个值记录锁只锁 20 这一条间隙锁锁(10, 20)这个范围允许你查 20但不允许往中间插入 15临键锁同时锁住(10, 20]也就是间隙加记录 20 本身。这里的关键点是InnoDB 的行锁全都要挂在索引上。如果表没有显式指定索引它会使用隐式主键如果 SQL 走了二级索引锁也会加在二级索引记录上。这也是很多人面试答不上来细节的根源——行锁这个名字容易让人以为锁的是数据行实际锁的是索引记录。3.2 意向锁表锁与行锁之间的桥梁有了行锁之后会出现一个新问题一个事务准备给表加表级锁时怎么快速知道这张表里是否存在行级锁如果没有辅助机制每次加表锁都得逐行扫描检查代价完全不可接受。InnoDB 的解法是引入意向锁事务准备给某几行加共享锁S时先给表加意向共享锁IS。事务准备给某几行加排他锁X时先给表加意向排他锁IX。意向锁是表级别的只有是否兼容这一个维度起作用。IS 和 IX 之间互相兼容因为它们表达的是后面我要加行锁而不是我要锁住整张表。但 IX 与表级的 S 锁冲突IS 与表级 X 锁冲突。举个例子事务 A 在 users 表的某一行加了行锁此时如果想对整张 users 表执行LOCK TABLES users WRITEMySQL 只需要看表上有没有 IX 锁有就直接判定冲突并等待完全不需要逐行检查。意向锁本质上是一种提前声明机制它让表锁和行锁之间的判断成本变成 O(1)。3.3 没走索引的行锁会退化成表锁这是大家在业务中踩得最深的一个坑。前面说过行锁挂在索引上但如果你的 UPDATE 或 DELETE 语句的 WHERE 条件没有索引MySQL 只能走全表扫描去筛选记录那么扫描过程中碰到的每一条记录都会被加上锁。从最终效果看整张表的所有记录都被锁住了和表锁没有本质区别区别只是底层实现走了行锁但阻塞范围覆盖了全表。举例说明-- 假设 users 表的 status 列没有索引 UPDATE users SET level 2 WHERE status 1;这条语句会扫描全表把每一行符合或不符合条件的记录都加锁实际是加临键锁取决于隔离级别然后才筛选出 status1 的行更新。在高并发业务里这种 SQL 一旦执行其他事务对 users 表任意一行的更新都会被阻塞线上表现就是一个慢 SQL 拖垮整张表。排查这个问题的思路也很简单先看执行计划EXPLAIN SELECT * FROM users WHERE status 1如果 type 列显示ALL说明走全表扫描这条 SQL 的锁范围就是全表。解决办法无非两个方向一是给 WHERE 条件加合适的索引让扫描范围缩小二是如果 status 的区分度太低比如只有两种取值加索引意义也不大就要从 SQL 本身重构比如分批更新避免一次性锁定太多记录。4. MVCC 与临键锁幻读的最后防线4.1 MVCC 到底在干什么MVCCMulti-Version Concurrency Control多版本并发控制是 InnoDB 实现高并发读的核心机制。它的大致思路是数据更新时不直接覆盖旧值而是通过 undo log 维护一个版本链每个事务都能基于自己的视图Read View找到应该看到的那个版本。这样做的好处是读操作不需要加锁也能保证读到的数据是一致的快照。具体来说InnoDB 里每行数据都有隐藏列DB_TRX_ID最近修改该行的事务 ID和DB_ROLL_PTR指向 undo log 中旧版本的指针。事务开启快照读时会生成一个 Read View里面记录了当时活跃事务的 ID 列表以及最小活跃事务 ID、最大事务 ID 等边界信息。判断一条记录是否可见的规则可以归纳为一句话只有已提交事务写入的版本或者自己事务写入的版本才对当前事务可见活跃事务写入的版本一律不可见。如果当前版本不可见就顺着 undo log 版本链往前找直到找到可见的旧版本。这里需要区分两个概念快照读和当前读。快照读普通SELECT不显式加锁。它依赖 MVCC 来读历史版本不需要加任何锁所以并发能力极高。当前读SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE、UPDATE、DELETE、INSERT这些操作必须读到最新已提交的数据因此需要加锁。MVCC 解决了快照读下的隔离问题但当前读仍然需要实实在在的锁来保护这就引出了临键锁。4.2 幻读为什么在 RR 下还会出现先明确幻读的定义同一个事务内执行两次相同的查询第二次查询多出了之前不存在的行。在 READ COMMITTED 隔离级别下快照读每次重新生成 Read View所以两次 SELECT 就可能看到不同的结果在 REPEATABLE READRR下快照读使用首次查询生成的 Read ViewMVCC 已经保证了快照读不会产生幻读。但是当前读不享受 MVCC 的快照保护。假设事务 T1 先执行了SELECT * FROM orders WHERE order_no 1000 FOR UPDATE锁住了现有记录此时事务 T2 插入了一条 order_no 1001 的新记录并提交。如果 T1 再次执行同样的当前读查询就会看到 T2 刚插入的行这就是幻读。要彻底禁止这种情况光锁已存在的记录不够还必须锁住未来的新记录可能出现的间隙——于是间隙锁和临键锁成为必须。4.3 临键锁的加锁规则与边界临键锁是Record Lock Gap Lock的组合锁区间是左开右闭(a, b]。为什么是左开因为间隙锁的语义是禁止在间隙中插入而记录本身已由记录锁保护所以把区间的左边界打开、右边界闭合正好覆盖了一条记录 它前面的空白区。仍以索引值 10、20、30 为例索引上的临键锁区间会被划分为四段(-∞, 10](10, 20](20, 30](30, ∞)不同的查询条件会决定加锁范围的大小这是临键锁最重要的实操知识点。第一种情况等值查询且命中唯一索引。比如SELECT * FROM users WHERE id 20 FOR UPDATE主键等值命中InnoDB 会把它降级为单纯的记录锁不加间隙锁。原因很直接主键唯一同一时刻不可能有另一个事务插入 id20 的记录即使不锁间隙也不可能出现幻读没必要扩大锁范围。第二种情况等值查询但未命中。比如执行SELECT * FROM users WHERE id 15 FOR UPDATE记录不存在。此时 InnoDB 会在最接近的间隙上锁也就是(10, 20)阻止其他事务插入 id 在 10 到 20 之间的任何记录。这样即使当前记录不存在也能保证同一个事务后续再次查询时这个结果不会突然多出记录。第三种情况范围查询。比如SELECT * FROM users WHERE id 10 AND id 20 FOR UPDATE涉及多个区间时InnoDB 会对所有被扫描到的记录加记录锁同时对记录之间的间隙加间隙锁合起来就是连续的临键锁。范围查询是扩大锁区间最典型的操作稍不注意就会锁住一大段索引阻塞大量插入操作。4.4 隔离级别对临键锁的影响临键锁并不是所有隔离级别下都会存在。在默认的 REPEATABLE READ 级别下InnoDB 对所有当前读操作默认使用临键锁来防止幻读。但在 READ COMMITTED 级别下间隙锁被禁用只剩记录锁幻读问题也不再被数据库层主动拦截。很多团队为了降低锁冲突、提升并发会主动把隔离级别调成 RC这个选择的风险点必须考虑到如果业务逻辑无法容忍并发的插入导致当前读结果变化那么换成 RC 后需要在业务层自己兜底比如对唯一键冲突做重试或者用分布式锁来控制关键路径。还有一个容易被忽略的细节临键锁只在索引扫描时生效。如果查询没走索引而走全表扫描RR 级别下 InnoDB 会对扫描到的所有索引记录加临键锁等于把整个表的插入、更新全阻塞了这也是慢 SQL 导致全表锁死的另一条路径。处理方式和 3.3 节说的一致优先加索引让锁范围缩小到合理的区间。5. 实操定位锁等待与死锁的完整流程5.1 查看锁信息的三把钥匙线上遇到锁问题时第一步不是猜而是把 MySQL 当前的锁现状拉出来。InnoDB 的锁信息主要藏在三处拿到手基本就能定位大部分问题。第一把钥匙是老牌的系统表-- 查看当前所有事务 SELECT * FROM information_schema.innodb_trx\G -- 查看当前锁等待关系 SELECT * FROM information_schema.innodb_lock_waits\Ginnodb_trx表里有事务 ID、事务开始时间、执行状态、等待锁的类型等关键信息。当某个事务长时间处于LOCK WAIT状态就要记下它的 trx_id再到innodb_lock_wait_waits找到它锁等待的关系链看是哪个事务握着它需要的锁。第二把钥匙是 MySQL 8.0 之后推荐使用的性能库-- 查看锁详情MySQL 8.0 起替代 innodb_locks SELECT * FROM performance_schema.data_locks\G -- 查看锁等待MySQL 8.0 起 SELECT * FROM performance_schema.data_lock_waits\Gdata_locks表非常详细能看到每个锁的LOCK_TYPETABLE 还是 RECORD、LOCK_MODES、X、GAP、REC_NOT_GAP 等、LOCK_INDEX、LOCK_DATA锁定的索引值和区间。看到LOCK_MODE里带GAP的就知道是间隙锁只有REC_NOT_GAP就是普通的记录锁X,GAP组合则说明是临键锁或专门间隙锁一眼就能看明白。第三把钥匙是大家最熟悉的死锁报告SHOW ENGINE INNODB STATUS\G在输出的LATEST DETECTED DEADLOCK段能看到最近一次死锁的完整事务信息包括两个事务各自执行的 SQL、持有和等待的锁以及最后的回滚对象。这是排查死锁的第一手现场证据务必养成死锁发生后先抓现场再处理的习惯。5.2 一个完整的锁等待排查过程说一个典型的场景某天线上告警订单表orders的更新超时率飙升。接到问题的第一件事不是重启服务而是登录数据库查事务SELECT trx_id, trx_state, trx_started, trx_query FROM information_schema.innodb_trx\G输出显示有一条 UPDATE 语句的事务状态是LOCK WAIT开始时间已经过去好几分钟明显不对劲。接着用data_lock_waits查它卡在哪里SELECT * FROM performance_schema.data_lock_waits\G可以看到一个锁等待链条事务 B 要的某一行记录锁正被事务 A 持有而事务 A 从几分钟前开始就一直不提交。回到innodb_trx确认事务 A 在做什么发现它是一条不带 WHERE 条件的大 UPDATE扫描了全表把几乎所有订单行都加了锁。这个问题的处理路径就很清晰了事务 A 是元凶它占用锁的时间太长、范围太大。先与业务方确认事务 A 是否可以安全 KILL如果它在处理关键批量任务也要评估止损然后执行-- 找到事务 A 的 trx_id 和对应的线程 IDkill 掉对应会话 KILL thread_id;事务 A 被终止后锁自然释放事务 B 会继续执行。事后处理分两步第一步优化引发全表锁的 SQL给 WHERE 条件加上合适的复合索引第二步在代码层面对批量更新做分批提交一条事务只更新几百行缩短持锁时间。这种排查流程我复制粘贴过很多次基本能覆盖 80% 以上的线上锁等待问题。5.3 死锁的典型成因与破局思路死锁最常见的形态是两个事务互相持有对方需要的锁。比如事务 A 先更新订单 1事务 B 先更新订单 2然后 A 想再更新订单 2B 想再更新订单 1两边都拿不到对方的锁就形成循环等待。InnoDB 内部有死锁检测机制当发现死锁时会主动回滚其中一个事务让另一个继续执行所以死锁并不会让数据库卡死但被回滚的事务会抛异常业务层如果不做重试就会出现失败请求。打破死锁的思路通常有三个方向。第一统一事务内多条 SQL 的访问顺序比如所有事务都先更新订单 1 再更新订单 2破坏循环等待的条件。第二减少持锁时间大事务拆小事务快速提交释放锁降低死锁概率。第三利用索引减少锁覆盖范围避免一个事务锁住过多记录让另一个事务无路可走。死锁虽然不能 100% 消除但在业务层加一层死锁重试捕获到死锁异常后随机等待几毫秒再执行一次是很务实的兜底手段。6. 常见问题与避坑经验速查6.1 高频问题速查表故障现象可能的锁相关原因处理建议某张表所有查询突然全部卡住长事务持有 MDL 读锁DDL 排队后阻塞后续全部请求查 metadata_locks 找到长事务kill 对应会话UPDATE 执行很慢且其他事务更新同一表被阻塞WHERE 条件没有索引行锁放大为全表锁用 EXPLAIN 检查执行计划补充合适索引并发插入时频繁等待吞吐上不去RR 隔离级别下插入了间隙锁的覆盖范围检查是否存在大范围更新/当前读语句优化锁范围业务日志出现 Deadlock 异常两个事务互相持有对方需要的锁统一加锁顺序拆分大事务业务层加重试自增插入在高并发下偶发等待AUTO-INC 锁在特殊插入路径下被触发确认 innodb_autoinc_lock_mode2避免混用显式自增值事务长时间不提交锁一直不释放应用层忘记提交或连接池持有事务排查应用代码设置事务超时与连接超时6.2 我在实际维护中学到的几条实在经验第一事务短是万金油。锁的持有时间基本等于事务的执行时间把无关查询、远程调用、计算逻辑统统移出事务只留下必要的更新语句持锁时间立刻缩短锁等待和死锁都会明显减少。第二设计索引时要带着锁范围的视角。以前加索引只想着查询快后来发现索引还决定锁的范围。一个区分度不高的索引会导致范围查询锁住大段区间阻塞插入。所以在 RR 隔离级别下范围查询和批量更新语句的索引设计判断标准不只是执行计划还有这条 SQL 会覆盖多少索引区间。第三临键锁不是洪水猛兽。很多团队一遇到间隙锁导致的插入阻塞就想着把隔离级别降到 RC 来绕开。这是治标不治本。真正值钱的思路是让事务走唯一索引等值路径把临键锁降级为记录锁既保留 RR 的防护能力又不扩大锁范围。举个例子批量更新时优先按主键分批而不是按业务筛选条件一批全更。第四把死锁信息当成改进素材。每次死锁发生后把SHOW ENGINE INNODB STATUS里的 SQL 和锁信息截图存档定期复盘很多隐藏的代码问题都是靠死锁报告暴露出来的。它不只是事故更像一份免费的并发问题诊断书。关于锁这个话题我个人的体会是表锁、行锁、临键锁并不是三个孤立的知识点它们串起来就是一句话——用不同粒度的锁在当前读路径上换取正确的并发结果。表锁成本最低但并发最差行锁精细化但依赖索引临键锁则在行锁之上补上了防未来插入的最后一块拼图。真正做业务的时候你不需要记太多优先级规则只需要在每次写 UPDATE、DELETE、范围查询之前多想一个问题这条 SQL 会在索引的哪些区间上留下锁别人往这个区间里插入会不会被堵住。想清楚这一点大部分锁问题都能在代码评审阶段就消掉。