从后端开发到DBA几乎每个人都会在某个深夜被MySQL的死锁告警叫醒。平时写SQL看着一切正常一旦并发一上来Deadlock found when trying to get lock这条报错就会冒出来紧接着业务超时、重试、数据错乱一套连招下来让人头皮发麻。锁机制这个东西属于那种“不懂也能跑懂了才能跑得稳”的知识尤其是InnoDB引擎下的行锁、间隙锁、临键锁以及它们之间相互组合产生的死锁场景不花点时间吃透线上迟早会给你上一课。这篇文章我打算从一个实际运维和开发的角度把MySQL锁机制的原理、常见死锁的产生路径、排查命令和实战解法完整串一遍。不管你是刚接触数据库的后端新人还是已经写过一段时间业务代码、想系统梳理锁知识的开发者或者是在公司里兼职运维需要处理线上锁等待的人这篇内容都会对你有用。文中会给出可以直接落地的SQL命令、排查思路和优化手段我也会把自己在实际环境中踩过的坑一并放进来算是给后来的朋友省点时间。1. 锁机制的整体设计与InnoDB核心锁类型1.1 为什么InnoDB要设计这么多种锁要理解MySQL的锁机制先得明白一个问题为什么不能只搞一种“锁”把所有操作都管住答案很简单因为并发场景下的需求是分层的有的操作只读、有的操作要写、有的操作锁一行就够、有的操作必须锁一个范围才能保证数据一致。如果所有场景都用一把大锁那数据库的并发能力直接归零连最简单的读都得排队性能完全没法看。InnoDB的设计思路是“按需加锁、尽量精细”。它把锁分成多个维度按模式分有共享锁和排他锁按粒度分有行锁和表锁按锁定范围分有记录锁、间隙锁、临键锁再加上表级别的意向锁这一套组合起来既能保证事务隔离性又能在大多数场景下把锁的粒度控制到最小。这套体系的核心目标是在不破坏数据一致性的前提下让尽可能多的读写操作并发执行。我在刚开始接触MySQL锁的时候也觉得很绕后来发现一个特别好的类比——你可以把数据库当成一个多人共用的办公室表锁就是把整个办公室锁住大家谁也进不去行锁是只锁住你正在用的那张办公桌别人还能用别的桌子间隙锁则像是你在桌子上画了一条“该区域暂时不许放新文件”的线防止有人在你工作过程中突然塞新文件进来。理解了这层逻辑后面再去看各种锁的名字就不会那么懵了。1.2 InnoDB锁模式与锁类型拆解InnoDB的锁模式其实只有两种核心类型共享锁Shared LockS锁和排他锁Exclusive LockX锁。S锁和S锁之间是兼容的也就是说多个事务可以同时读同一个资源S锁和X锁之间互斥X锁和X锁之间也互斥。这个兼容矩阵是整个锁机制的地基死锁的产生、锁等待的判断、并发度的上限都跟这张兼容表直接相关。在S锁和X锁之上InnoDB还加了一层意向锁Intention Lock分为意向共享锁和意向排他锁。意向锁是表级别的它的作用是快速判断“这张表里是否有行正在被锁定”避免每次加表锁时都要逐行扫描检查。比如一个事务要对某一行加X锁它必须先给表加一个意向排他锁另一个事务想直接对整个表加X锁时一看表上有意向排他锁就知道有行锁存在立刻阻塞。行锁的下层还有几种更精细的变体记录锁Record Lock锁的是索引记录本身间隙锁Gap Lock锁的是索引记录之间的间隙防止其他事务在这个区间插入数据临键锁Next-Key Lock是记录锁和间隙锁的合体同时锁住记录和它前面的间隙。InnoDB在可重复读RR隔离级别下做范围查询时默认就是用临键锁来封锁范围的这也是很多死锁问题的根源。2. 死锁的产生条件与典型场景2.1 死锁的四个必要条件死锁不是凭空冒出来的它必须在四个条件同时满足时才会发生互斥条件、持有并等待条件、不可剥夺条件、循环等待条件。在MySQL的语境里互斥指排他锁同一时刻只能被一个事务持有持有并等待指一个事务拿着自己的锁不释放还在等其他事务的锁不可剥夺指事务的锁不能被别的事务强行抢走循环等待指多个事务之间形成了一个“你等我、我等你”的闭环。这四个条件缺一不可所以理论上只要破坏其中任何一个死锁就不会发生。但在实际的数据库环境里互斥和不可剥夺是InnoDB锁机制设计上的硬约束不可能改掉持有并等待是事务的天然属性也没法消除。真正能动手优化的只有循环等待这一个条件——也就是想办法让所有事务以一致的顺序去访问资源。这个结论几乎贯穿了所有死锁优化的方案。很多人在网上看死锁文章觉得原理都懂但一遇到真实的死锁日志就不知道从哪看起。其实你只需要在死锁日志里找出两个事务各自的锁持有列表和锁等待列表画一个简单的依赖链条只要这个链条是环形的死锁原因就定位了。这个过程我们后面用实际日志演示一遍。2.2 AB-BA更新死锁最典型的互翻场景AB-BA死锁是业务代码里最容易踩中的一种它的触发过程非常直白事务A先更新了记录1再去更新记录2事务B先更新了记录2再去更新记录1。两个事务一开始都拿到了自己第一行数据的锁然后互相等对方释放另一行的锁循环等待形成死锁。写个具体的例子。假设有一张订单表里面有订单号字段业务代码里有这样两个并发请求请求A执行UPDATE orders SET status1 WHERE order_noA001紧接着执行UPDATE orders SET status2 WHERE order_noB002请求B执行顺序恰好相反先更新B002再更新A001。当这两个请求同时跑起来A拿到了A001的行锁B拿到了B002的行锁下一步A去要B002的锁被B阻塞B去要A001的锁被A阻塞死锁瞬间形成。这种问题的根源不在SQL本身写得有多糟糕而在事务内部多条UPDATE语句的访问顺序不一致。解决办法也直接在同一个事务里所有对订单表的更新都按同一个规则排序执行比如统一按订单号升序处理或者是把涉及的记录一次性锁定减少分步加锁的时间窗口。我在代码评审时看到事务里有连续多条更新语句都会提醒对方检查一下访问顺序是否全局一致。2.3 批量更新顺序不一致引发的死锁AB-BA是两条SQL互翻批量更新场景则是多条SQL分组互翻本质是一样的但排查起来更隐蔽。最常见的形态是业务里根据一批ID循环处理数据先查出一批记录再逐条更新由于查询结果的顺序受索引、数据分布、并发时数据变化的影响两个事务拿到的ID列表顺序可能完全不一致于是死锁就出现了。举个例子事务1查出ID列表是[3, 7, 9]事务2查出的是[7, 9, 3]然后各自按自己列表的顺序做更新。事务1先锁住3事务2先锁住7表面上看谁也不影响谁但继续往下走两边很快就因为抢对方的下一行而卡住。对这种场景我的建议是凡是涉及批量更新的事务更新前先对结果集做一次内存排序保证所有事务处理顺序一致。这个操作在代码里只是一次sort的事但在数据库层面能消灭掉一大类死锁。还有一个技巧是尽量把批量任务拆小一次别锁太多行减少两个事务锁定区间重叠的概率。锁的行越多互相交叉等待的可能性就越大这是个非常朴素的概率问题。2.4 间隙锁与插入意向锁造成的死锁间隙锁引出的死锁要更难理解一些因为它锁的不是真实存在的记录而是“两行数据之间的空隙”。在可重复读隔离级别下InnoDB为了阻止幻读范围查询时会把扫描覆盖到的间隙也锁住这样一来其他事务就无法在这个间隙里插入新数据从而达到“查询过程中数据集合不变化”的效果。间隙锁本身不可怕但当一个事务持有间隙锁另一个事务想在同一个间隙里插入数据而要获取插入意向锁时就会形成锁等待。如果两个事务各自持有了不同间隙的锁又同时需要往对方的间隙里插入数据循环等待就出现了。我在模拟环境里复现过这样一组操作事务1执行SELECT * FROM t WHERE id 10 AND id 20 FOR UPDATE事务2执行SELECT * FROM t WHERE id 30 AND id 40 FOR UPDATE然后事务1插入id35的数据事务2插入id15的数据两个操作都会因为间隙互锁而卡住最终触发死锁。这个场景在纯业务开发里不容易一眼看穿因为表面上看两条查询和两条插入根本不重叠。但数据库的锁范围判断是按索引区间来的不是按业务语义来的。理解这一点对排查那些“明明操作的不是同一批数据却锁死”的诡异线上事故非常关键。遇到这类死锁最直接的缓解手段是把隔离级别从RR降到RC读已提交RC下InnoDB会禁用间隙锁幻读风险需要业务层承担但很多互联网业务场景对这一点并不敏感收益却非常明显。3. 死锁排查的完整实战流程3.1 第一步查看死锁日志遇到死锁第一反应应该是去查InnoDB的死锁信息命令是SHOW ENGINE INNODB STATUS\G输出内容里有一节专门叫LATEST DETECTED DEADLOCK里面记录了最近一次死锁的完整细节参与死锁的事务各自的ID、执行的SQL、已经持有的锁、正在等待的锁以及MySQL最终选择回滚了哪个事务。这个日志是排查死锁的第一手资料但它的输出格式很不友好一堆十六进制的锁编号和内部结构体描述第一次看的人基本会懵。我分享一下我的阅读顺序先看*** (1) TRANSACTION和*** (2) TRANSACTION这两个段搞清楚是哪些SQL在参与然后看每段里的lock struct(s)和WAITING FOR THIS LOCK TO BE GRANTED这个就是在告诉你事务卡在哪个锁上最后看WE ROLL BACK TRANSACTION确认MySQL牺牲了哪个事务。把这两个事务的持有锁和等待锁画出来死锁链路基本就清楚了。值得注意的是这里的事务ID在日志里显示的是十六进制比如TRANSACTION 31100330而进程列表里显示的常规十进制ID是67952347对应起来看有点费劲。8.0版本的日志格式有所改进但老版本的日志还是十六进制的看到满屏数字别慌关注LATEST DETECTED DEADLOCK区域的结构就好。另外这个命令只能看到最近一次死锁的记录如果死锁频繁发生建议打开innodb_print_all_deadlocks参数把它设置为ON这样所有死锁都会写进MySQL错误日志不会因为只保留最近一条而丢失排查线索。3.2 第二步用系统表查询当前锁等待死锁日志适合事后分析但线上排查时你还需要实时看“现在正处于锁等待的事务是谁”。MySQL的系统表提供了两组查询入口老版本是在information_schema库里查INNODB_TRX和INNODB_LOCK_WAIT两个表8.0以后迁移到了performance_schema库的data_locks和data_lock_waits表。我常用的查询语句是这样写的一条直接得出哪个事务在阻塞哪个事务SELECT w.trx_id AS waiting_trx_id, w.trx_mysql_thread_id AS waiting_thread_id, w.trx_query AS waiting_query, b.trx_id AS blocking_trx_id, b.trx_mysql_thread_id AS blocking_thread_id, b.trx_query AS blocking_query FROM information_schema.INNODB_LOCK_WAIT w JOIN information_schema.INNODB_TRX b ON w.blocking_trx_id b.trx_id这个查询跑出来的结果非常直观左边是被阻塞等待的事务右边是持有锁不放的事务。拿到阻塞方的线程ID之后可以直接用SHOW PROCESSLIST看那个连接到底在干什么或者SELECT * FROM performance_schema.threads WHERE processlist_id 对方线程号追到具体会话。还要注意一个细节长期挂起的锁等待不一定就是死锁。死锁是循环等待被MySQL检测到了会主动回滚一方而单纯的锁等待可能是某个事务拿住锁后迟迟不提交把其他事务都堵死了。这种“假死锁”比真死锁更常见而且更难处理因为你需要找到那个“一直不释放锁”的会话判断它是在跑长事务、还是代码里漏了提交、还是连接池里挂了一个闲置未提交的连接。找出阻塞源头后最稳妥且影响最小的做法是执行KILL命令结束阻塞会话而不是去动数据库配置。3.3 第三步复现死锁并分析交互过程死锁日志和锁等待查询能告诉你死锁是什么但有时候还不够你需要在测试环境复现这个死锁理解它到底是怎么形成的才能在代码层面彻底修复。复现死锁的方法很简单开两个MySQL会话按怀疑的死锁路径手动执行SQL逐步验证锁的获取顺序。实际操作时我会用三个终端窗口两个跑事务一个专门观察锁情况。两个事务各自BEGIN后按顺序执行怀疑有问题的SQL在每一步之间用第三个窗口查一下data_locks表看这两个事务各自持有的是什么锁、锁的区间是什么。如果手动执行能稳定触发死锁那原因就100%确认了如果执行不出来就说明生产环境的死锁可能还和当时的数据分布、索引选择有关需要进一步构造数据。这里有一个我一直强调的小技巧复现死锁前把事务隔离级别和当前的索引情况先摸清楚。同一个死锁场景在RR下很容易复现把隔离级别改成RC后可能就怎么也复现不出来了这本身就是一条重要线索——说明死锁跟间隙锁有关。索引也是一样UPDATE语句如果走不同的索引锁定范围就完全不同死锁路径也会不一样。3.4 第四步把死锁日志翻译成人话我见过太多的同事拿到死锁日志后一头雾水其实翻译成人话后就是一层窗户纸。我总结了一个模板拿到日志后按这个模板套就行第1行写“事务1做了什么已经锁住什么”第2行写“事务1正在等什么”第3行写“事务2做了什么已经锁住什么”第4行写“事务2正在等什么”。如果事务1等的正是事务2持有的事务2等的正是事务1持有的闭环形成死锁原因定位完成。用一次真实的死锁日志片段来说明。日志里会有一大段类似下面的关键信息*** (1) TRANSACTION: TRANSACTION 31100330, ACTIVE 5 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s) *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 2 page no 5 n bits 72 index PRIMARY of table test.t *** (2) TRANSACTION: TRANSACTION 31100331, ACTIVE 4 sec starting index read LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s) *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 2 page no 5 n bits 72 index PRIMARY of table test.t翻译一下就非常清楚事务31100330在等一把锁事务31100331也在等一把锁而且它们等的锁都在同一张表同一个索引上。再往日志下面看能看到两个事务各自已经持有的锁记录事务1持有id为某一行的X锁事务2持有另一行的X锁它们等的恰好是对方已经拿到的行。在实际排查时我不会只看日志里的SQL语句因为死锁日志里记录的SQL往往只是“正在执行的SQL”导致它持有锁的语句可能是这条SQL的前一条。也就是说死锁日志显示的语句是事务当前执行的最后一条而锁可能是这个事务一开始就获取的。所以定位问题时一定要把整个事务的事务体拉出来看不要只盯着死锁日志那一行SQL纠结。4. 死锁的恢复机制与参数调优4.1 InnoDB的死锁检测与回滚策略InnoDB并不是等到死锁真的把数据库拖垮了才开始处理它内部有一个死锁检测机制原理是维护一张“锁等待关系图”每当一个事务等待某个锁时就检测一下这个等待关系图里是否出现了环形结构如果检测到环就会立即选择一个代价较小的事务作为牺牲品回滚这个事务并释放它持有的锁让另一个事务得以继续执行。这个“代价较小”是怎么衡量的InnoDB的判定逻辑大致是看事务已经修改了多少行、是否已经写入了undo log、持有锁的数量等优先回滚修改量小、持有锁少的事务。这也是为什么日志里会出现WE ROLL BACK TRANSACTION (1)这样的语句数字分别对应日志中标记的第几个事务。理解这一点对业务代码非常重要死锁发生时必然有一个事务会收到Deadlock found错误被回滚另一个事务大概率能执行成功。所以业务侧的应对策略就是——捕获死锁错误后对回滚的事务做有限次数的重试。把死锁当作一种偶发的冲突而不是数据库故障这种心态在开发高并发业务时非常必要。4.2 关键参数innodb_lock_wait_timeout与innodb_deadlock_detect跟死锁和锁等待相关的有两个核心参数一个是innodb_lock_wait_timeout一个是innodb_deadlock_detect。前者控制一个事务等待获取锁的最长时间默认值是50秒超过这个时间就报Lock wait timeout exceeded错误。后者控制是否启用死锁检测默认是ON。很多人把这两个参数搞混其实它们的职责完全不同。innodb_lock_wait_timeout处理的是“非死锁的长时间锁等待”也就是一个事务单纯地等着另一个事务释放锁等太久就超时放弃innodb_deadlock_detect处理的是“两个事务互相等导致闭环”的情况检测到了就立刻回滚一方不需要等超时。生产环境里这个超时时间设置多少合适要看业务容忍度。如果你业务里很多短事务那50秒显然太长用户可以等但数据库连接池里的连接不一定扛得住建议调小一些比如10秒左右如果你的业务里确实存在长事务调得太小会导致正常业务频繁报错。我在实际中遇到过一个案例某系统把innodb_lock_wait_timeout调成了100秒结果一个更新操作卡住后几十个后续请求全部排队等锁连接池直接被拖垮。后来把这参数改回15秒并优化了事务内的SQL执行顺序问题立刻消失。至于innodb_deadlock_detect官方文档说在高并发场景下如果死锁检测本身成为性能瓶颈可以考虑把它关闭然后依赖innodb_lock_wait_timeout来兜底。但说实话这种情况非常罕见绝大数业务根本到不了那个并发量级贸然关闭死锁检测反而可能让死锁长时间占用连接。我的建议是没有经过严格压测论证不要关闭这个参数。4.3 事务大小与持锁时间对锁竞争的影响锁竞争的本质是“多个事务同时想访问同一批资源”而事务的大小和持锁时间直接决定了竞争窗口的大小。一个事务里执行10条SQL和100条SQL前者持锁时间通常远小于后者一个包含用户交互的长事务如果在里面开了事务后去调远程接口持锁时间可能长达几百毫秒甚至几秒这段时间内所有需要访问相同数据的事务都被堵住了。有一类非常典型的线上锁等待问题是代码里事务内嵌了外部调用BEGIN- 更新订单状态 - 调用支付回调接口 - 更新其他表 -COMMIT。如果回调接口响应慢整个事务就一直持有订单行的锁任何对这个订单的操作全部排队。这个问题在代码Review阶段就必须拦截。事务里绝对不能有网络IO这是我在很多次事故复盘后总结出来的一条铁律。把事务拆小是减少锁竞争最有效的手段之一。我见过有些同事习惯把一大坨写操作塞进一个事务里理由是怕数据不一致其实只要拆分合理配合幂等设计一致性完全可以通过补偿机制来保证而锁竞争和死锁的概率能下降一个数量级。事务短小永远是对的事务越长持锁越久风险越高。5. 减少死锁的实战优化手段5.1 统一索引访问路径与更新顺序所有业务SQL在更新数据时尽量走同一个索引这是我从实践中总结出的减少死锁的第一守则。原理很简单行锁挂在索引记录上如果两个事务对同一行数据使用不同的索引来定位那么它们加锁的顺序、加锁的区间就不一致很容易出现交叉等待。举个例子订单表上有主键id、订单号order_no、用户id user_id三个索引。事务1用WHERE id100去更新一行事务2用WHERE order_noABC100去更新同一行看起来都能命中同一行数据但加锁时一个直接锁主键索引记录另一个先走二级索引拿到主键值再回表锁主键记录加锁路径不同配合其他语句就可能产生意想不到的等待关系。所以业务里定位同一行数据时尽量统一用同一个字段。更新顺序的问题前面已经讲过这里再强化一下同一事务里涉及多行数据更新务必按主键或者某个业务唯一键排序后统一顺序执行。这个规则不只在单表内有效跨表更新也一样事务1先更新A表再更新B表事务2也应该先更新A表再更新B表。只要全局所有事务都遵守同一套访问顺序循环等待这个必要条件就被破坏了死锁自然消失。5.2 缩小锁定范围与合理设计索引锁的范围越大冲突概率越高这是一个数学上的必然。缩小锁定范围可以从两个方向入手一是让UPDATE或DELETE语句尽可能走索引避免全表扫描导致的行锁“伪表锁”效果二是让扫描的区间尽可能小用更精确的WHERE条件。InnoDB的行锁机制依赖索引来实现如果没有索引可用InnoDB只能全表扫描来定位目标行每扫到一行就会对这行加锁。表面上看你只是想更新一行数据实际整个表的行都被锁过了虽然最终只持有一部分锁但扫描过程中产生的其他行锁会阻塞其他事务对这些行的操作触发大量锁等待和死锁。经典的优化手段是在WHERE条件涉及的字段上建立合适的联合索引让更新语句的锁定范围精确收缩。我处理过这样一个问题某表daily_report按日期字段更新当天报表数据但日期字段没有索引UPDATE语句每次全表扫描多个批次并发执行时频繁死锁。后来在日期字段上加了一个普通索引死锁数量直接降到了接近零。这个案例非常典型SQL本身没变就是路径变了结果天差地别。5.3 隔离级别选择RR与RC的本质差异隔离级别对锁行为的影响非常大尤其在间隙锁问题上。默认的RR隔离级别会启用临键锁和间隙锁来防止幻读而RC隔离级别只用记录锁不控制间隙所以死锁概率显著降低代价是会出现不可重复读和幻读的可能。我在很多业务团队里看到的现象是大家用了好几年MySQL但从来没人去思考过“系统到底需不需要RR”。对于多数OLTP业务来说RC完全够用而且收益很明显锁粒度更小并发度更高死锁发生频率大幅下降。特别是那些以UPDATE为主、对幻读不敏感的业务切到RC之后效果立竿见影。切隔离级别要谨慎的一点是如果业务代码里存在依赖“同一事务内两次SELECT结果一致”的逻辑比如先查余额再扣款、先查库存再下单这类操作切到RC后就需要引入额外的行锁例如SELECT ... FOR UPDATE来保护逻辑否则数据一致性可能出问题。改隔离级别不是简单的参数变更得跟着Review一遍业务逻辑。5.4 应用层重试与降级策略不管你把优化做得多么到位死锁在极端并发下依然可能发生因为数据库层面无法完全消除共享资源的争用。所以应用层的兜底策略——捕获死锁异常并重试——是必须的。我在代码规范里一般要求所有写操作都加上死锁重试逻辑重试次数建议3次每次重试间隔可以非常短几十毫秒即可。这里有一个容易踩的坑重试整个事务时如果事务内某些操作不是幂等的就会造成重复更新或者重复插入。比如事务里有INSERT语句重试时如果没有唯一键约束做保护就可能插出两条数据。所以设计重试方案时必须考虑幂等性——要么保证事务内有天然的幂等键要么在事务外先做好去重。除了重试还有更高级一点的降级策略当死锁频繁发生时可以在应用层做并发限流比如按订单号或用户ID哈希后分桶同一桶内的操作串行执行。这个方法相当于把数据库层面的并发竞争提前到应用层解决虽然牺牲了一点吞吐但换来了极强的稳定性。对于核心交易链路我倾向于用这种偏保守的方案稳比快重要得多。6. 独家避坑经验与高频问题速查6.1 容易忽略的死锁触发点有几个死锁诱因是那种平时不起眼、一旦出事就非常难查的。第一个是INSERT ... ON DUPLICATE KEY UPDATE很多人觉得这就是一条语句应该不会锁冲突其实它在唯一键冲突时会对冲突记录加X锁并发插入同一条记录时同样会死锁。第二个是外键约束子表插入时会对父表记录加S锁多个事务插入引用同一父记录的子记录时S锁之间本来兼容但配合后续更新就可能升级成复杂等待。第三个是ALTER TABLE造成元数据锁MDL阻塞。元数据锁不在InnoDB存储引擎层而是在MySQL Server层但它能让所有DML语句全部排队。很多时候线上出现大面积锁等待排查半天发现不是行锁问题而是一个DDL操作把整张表的读写全堵住了。查锁等待的时候一定要顺手看一眼是否有Waiting for table metadata lock状态的会话。第四个隐藏触发点是一致性读与当前读混合使用。事务里先做普通的SELECT快照读再做UPDATE当前读如果数据在两步之间被其他事务修改了就会触发锁的获取和等待配合其他事务的操作也容易产生死锁。这种场景表面上看不太出来因为两条语句根本没有明显的锁冲突但加上间隙锁后就全变了。6.2 如何快速判断是死锁还是单纯阻塞这是个非常实际的问题因为两个场景的报错信息不一样处理方式也不一样搞混了会浪费大量时间。死锁的报错是Deadlock found when trying to get lock; try restarting transaction这个错误发生得非常快几乎不需要等50秒。单纯的锁阻塞报的是Lock wait timeout exceeded; try restarting transaction它是等满了超时时间之后才抛出的。判断方法除了看报错文案还能看时间线。如果一个操作立刻报死锁错误说明InnoDB的死锁检测直接发现了循环等待如果一个操作卡了几秒甚至几十秒后报超时说明是单纯的锁等待背后一定有个长事务持锁不释放。拿到这个判断之后处理手段截然不同死锁要查SQL顺序、索引、锁区间阻塞要查长事务、连接池、事务内的外部调用。我在团队里经常给新同学开小灶讲这个区分方法。有一次线上告警开发同学一口咬定是死锁结果我一看错误日志全是Lock wait timeout顺着阻塞链找下去发现是一个后台跑批任务开着事务批量更新中间还睡了好几秒把整张表的更新操作都堵住了。方向不对排查再久也徒劳。6.3 一个解决死锁问题的通用排查清单长期处理死锁问题之后我总结了一个排查清单遇到死锁直接照着走通常不需要太久就能定位到根因先确认报错类型是Deadlock found还是Lock wait timeout这两者的处理方向完全不同。执行SHOW ENGINE INNODB STATUS\G取出LATEST DETECTED DEADLOCK部分翻译出两个事务的持有锁和等待锁。拉出两个事务的完整业务代码上下文重点看事务体内所有SQL的执行顺序特别是每条SQL走的索引。用系统表查当前是否存在其他锁等待事务排除“已经恢复正常日志只是历史记录”的情况。检查索引使用情况确认UPDATE和DELETE语句是否命中合适索引锁定范围是否远比业务所需更大。确认隔离级别是否高于业务实际需求评估是否可以从RR降到RC。检查事务体内是否包含外部调用、大循环、批量操作等延长持锁时间的代码。在所有写操作入口加上死锁重试逻辑并确保重试不会破坏幂等性。这份清单我几乎是每个月都会用到一次。实际上线的时候大多数死锁问题走到第5步也就定位到了走到第7步的往往是那种跟锁关系不大但制造了锁竞争的长事务问题。把这份清单交给团队后端同学让他们排查死锁时有个标准动作比自己挨个去救火要高效得多。6.4 生产环境死锁案例复盘与思考最后分享一个我自己处理过的案例完整走一遍排查闭环。某天线上核心服务突然告警增多日志里大量死锁错误涉及两张表用户账户表account和账户流水表account_log。业务逻辑是事务内先往account_log插入一条流水再更新account表的余额字段。刚开始所有人都很困惑因为从逻辑上看插入流水是往一张表加记录更新余额是改另一张表的行各自独立怎么会死锁我把死锁日志拉出来一翻译发现事务1持有account表中某行的锁在等account_log表的插入意向锁事务2持有account_log表的插入意向锁在等account表中同一行的锁。两条锁等待路径直接形成一个闭环死锁成立。停顿了一下问了开发同学一个问题这两条SQL是不是反过来了开发确认事务1是先插流水再改余额事务2是先改余额再插流水。两个事务对两张表的访问顺序不一致和AB-BA死锁的底层逻辑一模一样只是跨表了而已。解决方案也很简单——统一所有事务对这两张表的操作顺序全部改成先改account再插account_log。上线后死锁消失一个告警都没再出现过。这个案例我经常拿来给团队讲因为它说明了一个核心道理死锁的根源往往不是数据库而是业务代码对共享资源的访问顺序不一致。锁机制只是把这个问题暴露出来真正修复它的地方在业务代码里。理解这一点比背一百条死锁报错处理办法都有用。个人经验之谈排查死锁这么多年我最深的体会是死锁问题没有那么多“高深莫测”绝大部分都是访问顺序问题、索引路径问题、事务大小问题这三类。把这三类问题在设计和Review阶段就控制住线上遇到死锁的概率能降低八成以上。真等到死在日志里跟你打招呼再做优化代价就大了。 
长河君 · 2026/10/15 5:16:09 · 阅读 1.2k MySQL死锁实战：InnoDB锁机制、排查命令与优化方案全解析
从后端开发到DBA几乎每个人都会在某个深夜被MySQL的死锁告警叫醒。平时写SQL看着一切正常一旦并发一上来Deadlock found when trying to get lock这条报错就会冒出来紧接着业务超时、重试、数据错乱一套连招下来让人头皮发麻。锁机制这个东西属于那种“不懂也能跑懂了才能跑得稳”的知识尤其是InnoDB引擎下的行锁、间隙锁、临键锁以及它们之间相互组合产生的死锁场景不花点时间吃透线上迟早会给你上一课。这篇文章我打算从一个实际运维和开发的角度把MySQL锁机制的原理、常见死锁的产生路径、排查命令和实战解法完整串一遍。不管你是刚接触数据库的后端新人还是已经写过一段时间业务代码、想系统梳理锁知识的开发者或者是在公司里兼职运维需要处理线上锁等待的人这篇内容都会对你有用。文中会给出可以直接落地的SQL命令、排查思路和优化手段我也会把自己在实际环境中踩过的坑一并放进来算是给后来的朋友省点时间。1. 锁机制的整体设计与InnoDB核心锁类型1.1 为什么InnoDB要设计这么多种锁要理解MySQL的锁机制先得明白一个问题为什么不能只搞一种“锁”把所有操作都管住答案很简单因为并发场景下的需求是分层的有的操作只读、有的操作要写、有的操作锁一行就够、有的操作必须锁一个范围才能保证数据一致。如果所有场景都用一把大锁那数据库的并发能力直接归零连最简单的读都得排队性能完全没法看。InnoDB的设计思路是“按需加锁、尽量精细”。它把锁分成多个维度按模式分有共享锁和排他锁按粒度分有行锁和表锁按锁定范围分有记录锁、间隙锁、临键锁再加上表级别的意向锁这一套组合起来既能保证事务隔离性又能在大多数场景下把锁的粒度控制到最小。这套体系的核心目标是在不破坏数据一致性的前提下让尽可能多的读写操作并发执行。我在刚开始接触MySQL锁的时候也觉得很绕后来发现一个特别好的类比——你可以把数据库当成一个多人共用的办公室表锁就是把整个办公室锁住大家谁也进不去行锁是只锁住你正在用的那张办公桌别人还能用别的桌子间隙锁则像是你在桌子上画了一条“该区域暂时不许放新文件”的线防止有人在你工作过程中突然塞新文件进来。理解了这层逻辑后面再去看各种锁的名字就不会那么懵了。1.2 InnoDB锁模式与锁类型拆解InnoDB的锁模式其实只有两种核心类型共享锁Shared LockS锁和排他锁Exclusive LockX锁。S锁和S锁之间是兼容的也就是说多个事务可以同时读同一个资源S锁和X锁之间互斥X锁和X锁之间也互斥。这个兼容矩阵是整个锁机制的地基死锁的产生、锁等待的判断、并发度的上限都跟这张兼容表直接相关。在S锁和X锁之上InnoDB还加了一层意向锁Intention Lock分为意向共享锁和意向排他锁。意向锁是表级别的它的作用是快速判断“这张表里是否有行正在被锁定”避免每次加表锁时都要逐行扫描检查。比如一个事务要对某一行加X锁它必须先给表加一个意向排他锁另一个事务想直接对整个表加X锁时一看表上有意向排他锁就知道有行锁存在立刻阻塞。行锁的下层还有几种更精细的变体记录锁Record Lock锁的是索引记录本身间隙锁Gap Lock锁的是索引记录之间的间隙防止其他事务在这个区间插入数据临键锁Next-Key Lock是记录锁和间隙锁的合体同时锁住记录和它前面的间隙。InnoDB在可重复读RR隔离级别下做范围查询时默认就是用临键锁来封锁范围的这也是很多死锁问题的根源。2. 死锁的产生条件与典型场景2.1 死锁的四个必要条件死锁不是凭空冒出来的它必须在四个条件同时满足时才会发生互斥条件、持有并等待条件、不可剥夺条件、循环等待条件。在MySQL的语境里互斥指排他锁同一时刻只能被一个事务持有持有并等待指一个事务拿着自己的锁不释放还在等其他事务的锁不可剥夺指事务的锁不能被别的事务强行抢走循环等待指多个事务之间形成了一个“你等我、我等你”的闭环。这四个条件缺一不可所以理论上只要破坏其中任何一个死锁就不会发生。但在实际的数据库环境里互斥和不可剥夺是InnoDB锁机制设计上的硬约束不可能改掉持有并等待是事务的天然属性也没法消除。真正能动手优化的只有循环等待这一个条件——也就是想办法让所有事务以一致的顺序去访问资源。这个结论几乎贯穿了所有死锁优化的方案。很多人在网上看死锁文章觉得原理都懂但一遇到真实的死锁日志就不知道从哪看起。其实你只需要在死锁日志里找出两个事务各自的锁持有列表和锁等待列表画一个简单的依赖链条只要这个链条是环形的死锁原因就定位了。这个过程我们后面用实际日志演示一遍。2.2 AB-BA更新死锁最典型的互翻场景AB-BA死锁是业务代码里最容易踩中的一种它的触发过程非常直白事务A先更新了记录1再去更新记录2事务B先更新了记录2再去更新记录1。两个事务一开始都拿到了自己第一行数据的锁然后互相等对方释放另一行的锁循环等待形成死锁。写个具体的例子。假设有一张订单表里面有订单号字段业务代码里有这样两个并发请求请求A执行UPDATE orders SET status1 WHERE order_noA001紧接着执行UPDATE orders SET status2 WHERE order_noB002请求B执行顺序恰好相反先更新B002再更新A001。当这两个请求同时跑起来A拿到了A001的行锁B拿到了B002的行锁下一步A去要B002的锁被B阻塞B去要A001的锁被A阻塞死锁瞬间形成。这种问题的根源不在SQL本身写得有多糟糕而在事务内部多条UPDATE语句的访问顺序不一致。解决办法也直接在同一个事务里所有对订单表的更新都按同一个规则排序执行比如统一按订单号升序处理或者是把涉及的记录一次性锁定减少分步加锁的时间窗口。我在代码评审时看到事务里有连续多条更新语句都会提醒对方检查一下访问顺序是否全局一致。2.3 批量更新顺序不一致引发的死锁AB-BA是两条SQL互翻批量更新场景则是多条SQL分组互翻本质是一样的但排查起来更隐蔽。最常见的形态是业务里根据一批ID循环处理数据先查出一批记录再逐条更新由于查询结果的顺序受索引、数据分布、并发时数据变化的影响两个事务拿到的ID列表顺序可能完全不一致于是死锁就出现了。举个例子事务1查出ID列表是[3, 7, 9]事务2查出的是[7, 9, 3]然后各自按自己列表的顺序做更新。事务1先锁住3事务2先锁住7表面上看谁也不影响谁但继续往下走两边很快就因为抢对方的下一行而卡住。对这种场景我的建议是凡是涉及批量更新的事务更新前先对结果集做一次内存排序保证所有事务处理顺序一致。这个操作在代码里只是一次sort的事但在数据库层面能消灭掉一大类死锁。还有一个技巧是尽量把批量任务拆小一次别锁太多行减少两个事务锁定区间重叠的概率。锁的行越多互相交叉等待的可能性就越大这是个非常朴素的概率问题。2.4 间隙锁与插入意向锁造成的死锁间隙锁引出的死锁要更难理解一些因为它锁的不是真实存在的记录而是“两行数据之间的空隙”。在可重复读隔离级别下InnoDB为了阻止幻读范围查询时会把扫描覆盖到的间隙也锁住这样一来其他事务就无法在这个间隙里插入新数据从而达到“查询过程中数据集合不变化”的效果。间隙锁本身不可怕但当一个事务持有间隙锁另一个事务想在同一个间隙里插入数据而要获取插入意向锁时就会形成锁等待。如果两个事务各自持有了不同间隙的锁又同时需要往对方的间隙里插入数据循环等待就出现了。我在模拟环境里复现过这样一组操作事务1执行SELECT * FROM t WHERE id 10 AND id 20 FOR UPDATE事务2执行SELECT * FROM t WHERE id 30 AND id 40 FOR UPDATE然后事务1插入id35的数据事务2插入id15的数据两个操作都会因为间隙互锁而卡住最终触发死锁。这个场景在纯业务开发里不容易一眼看穿因为表面上看两条查询和两条插入根本不重叠。但数据库的锁范围判断是按索引区间来的不是按业务语义来的。理解这一点对排查那些“明明操作的不是同一批数据却锁死”的诡异线上事故非常关键。遇到这类死锁最直接的缓解手段是把隔离级别从RR降到RC读已提交RC下InnoDB会禁用间隙锁幻读风险需要业务层承担但很多互联网业务场景对这一点并不敏感收益却非常明显。3. 死锁排查的完整实战流程3.1 第一步查看死锁日志遇到死锁第一反应应该是去查InnoDB的死锁信息命令是SHOW ENGINE INNODB STATUS\G输出内容里有一节专门叫LATEST DETECTED DEADLOCK里面记录了最近一次死锁的完整细节参与死锁的事务各自的ID、执行的SQL、已经持有的锁、正在等待的锁以及MySQL最终选择回滚了哪个事务。这个日志是排查死锁的第一手资料但它的输出格式很不友好一堆十六进制的锁编号和内部结构体描述第一次看的人基本会懵。我分享一下我的阅读顺序先看*** (1) TRANSACTION和*** (2) TRANSACTION这两个段搞清楚是哪些SQL在参与然后看每段里的lock struct(s)和WAITING FOR THIS LOCK TO BE GRANTED这个就是在告诉你事务卡在哪个锁上最后看WE ROLL BACK TRANSACTION确认MySQL牺牲了哪个事务。把这两个事务的持有锁和等待锁画出来死锁链路基本就清楚了。值得注意的是这里的事务ID在日志里显示的是十六进制比如TRANSACTION 31100330而进程列表里显示的常规十进制ID是67952347对应起来看有点费劲。8.0版本的日志格式有所改进但老版本的日志还是十六进制的看到满屏数字别慌关注LATEST DETECTED DEADLOCK区域的结构就好。另外这个命令只能看到最近一次死锁的记录如果死锁频繁发生建议打开innodb_print_all_deadlocks参数把它设置为ON这样所有死锁都会写进MySQL错误日志不会因为只保留最近一条而丢失排查线索。3.2 第二步用系统表查询当前锁等待死锁日志适合事后分析但线上排查时你还需要实时看“现在正处于锁等待的事务是谁”。MySQL的系统表提供了两组查询入口老版本是在information_schema库里查INNODB_TRX和INNODB_LOCK_WAIT两个表8.0以后迁移到了performance_schema库的data_locks和data_lock_waits表。我常用的查询语句是这样写的一条直接得出哪个事务在阻塞哪个事务SELECT w.trx_id AS waiting_trx_id, w.trx_mysql_thread_id AS waiting_thread_id, w.trx_query AS waiting_query, b.trx_id AS blocking_trx_id, b.trx_mysql_thread_id AS blocking_thread_id, b.trx_query AS blocking_query FROM information_schema.INNODB_LOCK_WAIT w JOIN information_schema.INNODB_TRX b ON w.blocking_trx_id b.trx_id这个查询跑出来的结果非常直观左边是被阻塞等待的事务右边是持有锁不放的事务。拿到阻塞方的线程ID之后可以直接用SHOW PROCESSLIST看那个连接到底在干什么或者SELECT * FROM performance_schema.threads WHERE processlist_id 对方线程号追到具体会话。还要注意一个细节长期挂起的锁等待不一定就是死锁。死锁是循环等待被MySQL检测到了会主动回滚一方而单纯的锁等待可能是某个事务拿住锁后迟迟不提交把其他事务都堵死了。这种“假死锁”比真死锁更常见而且更难处理因为你需要找到那个“一直不释放锁”的会话判断它是在跑长事务、还是代码里漏了提交、还是连接池里挂了一个闲置未提交的连接。找出阻塞源头后最稳妥且影响最小的做法是执行KILL命令结束阻塞会话而不是去动数据库配置。3.3 第三步复现死锁并分析交互过程死锁日志和锁等待查询能告诉你死锁是什么但有时候还不够你需要在测试环境复现这个死锁理解它到底是怎么形成的才能在代码层面彻底修复。复现死锁的方法很简单开两个MySQL会话按怀疑的死锁路径手动执行SQL逐步验证锁的获取顺序。实际操作时我会用三个终端窗口两个跑事务一个专门观察锁情况。两个事务各自BEGIN后按顺序执行怀疑有问题的SQL在每一步之间用第三个窗口查一下data_locks表看这两个事务各自持有的是什么锁、锁的区间是什么。如果手动执行能稳定触发死锁那原因就100%确认了如果执行不出来就说明生产环境的死锁可能还和当时的数据分布、索引选择有关需要进一步构造数据。这里有一个我一直强调的小技巧复现死锁前把事务隔离级别和当前的索引情况先摸清楚。同一个死锁场景在RR下很容易复现把隔离级别改成RC后可能就怎么也复现不出来了这本身就是一条重要线索——说明死锁跟间隙锁有关。索引也是一样UPDATE语句如果走不同的索引锁定范围就完全不同死锁路径也会不一样。3.4 第四步把死锁日志翻译成人话我见过太多的同事拿到死锁日志后一头雾水其实翻译成人话后就是一层窗户纸。我总结了一个模板拿到日志后按这个模板套就行第1行写“事务1做了什么已经锁住什么”第2行写“事务1正在等什么”第3行写“事务2做了什么已经锁住什么”第4行写“事务2正在等什么”。如果事务1等的正是事务2持有的事务2等的正是事务1持有的闭环形成死锁原因定位完成。用一次真实的死锁日志片段来说明。日志里会有一大段类似下面的关键信息*** (1) TRANSACTION: TRANSACTION 31100330, ACTIVE 5 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s) *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 2 page no 5 n bits 72 index PRIMARY of table test.t *** (2) TRANSACTION: TRANSACTION 31100331, ACTIVE 4 sec starting index read LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s) *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 2 page no 5 n bits 72 index PRIMARY of table test.t翻译一下就非常清楚事务31100330在等一把锁事务31100331也在等一把锁而且它们等的锁都在同一张表同一个索引上。再往日志下面看能看到两个事务各自已经持有的锁记录事务1持有id为某一行的X锁事务2持有另一行的X锁它们等的恰好是对方已经拿到的行。在实际排查时我不会只看日志里的SQL语句因为死锁日志里记录的SQL往往只是“正在执行的SQL”导致它持有锁的语句可能是这条SQL的前一条。也就是说死锁日志显示的语句是事务当前执行的最后一条而锁可能是这个事务一开始就获取的。所以定位问题时一定要把整个事务的事务体拉出来看不要只盯着死锁日志那一行SQL纠结。4. 死锁的恢复机制与参数调优4.1 InnoDB的死锁检测与回滚策略InnoDB并不是等到死锁真的把数据库拖垮了才开始处理它内部有一个死锁检测机制原理是维护一张“锁等待关系图”每当一个事务等待某个锁时就检测一下这个等待关系图里是否出现了环形结构如果检测到环就会立即选择一个代价较小的事务作为牺牲品回滚这个事务并释放它持有的锁让另一个事务得以继续执行。这个“代价较小”是怎么衡量的InnoDB的判定逻辑大致是看事务已经修改了多少行、是否已经写入了undo log、持有锁的数量等优先回滚修改量小、持有锁少的事务。这也是为什么日志里会出现WE ROLL BACK TRANSACTION (1)这样的语句数字分别对应日志中标记的第几个事务。理解这一点对业务代码非常重要死锁发生时必然有一个事务会收到Deadlock found错误被回滚另一个事务大概率能执行成功。所以业务侧的应对策略就是——捕获死锁错误后对回滚的事务做有限次数的重试。把死锁当作一种偶发的冲突而不是数据库故障这种心态在开发高并发业务时非常必要。4.2 关键参数innodb_lock_wait_timeout与innodb_deadlock_detect跟死锁和锁等待相关的有两个核心参数一个是innodb_lock_wait_timeout一个是innodb_deadlock_detect。前者控制一个事务等待获取锁的最长时间默认值是50秒超过这个时间就报Lock wait timeout exceeded错误。后者控制是否启用死锁检测默认是ON。很多人把这两个参数搞混其实它们的职责完全不同。innodb_lock_wait_timeout处理的是“非死锁的长时间锁等待”也就是一个事务单纯地等着另一个事务释放锁等太久就超时放弃innodb_deadlock_detect处理的是“两个事务互相等导致闭环”的情况检测到了就立刻回滚一方不需要等超时。生产环境里这个超时时间设置多少合适要看业务容忍度。如果你业务里很多短事务那50秒显然太长用户可以等但数据库连接池里的连接不一定扛得住建议调小一些比如10秒左右如果你的业务里确实存在长事务调得太小会导致正常业务频繁报错。我在实际中遇到过一个案例某系统把innodb_lock_wait_timeout调成了100秒结果一个更新操作卡住后几十个后续请求全部排队等锁连接池直接被拖垮。后来把这参数改回15秒并优化了事务内的SQL执行顺序问题立刻消失。至于innodb_deadlock_detect官方文档说在高并发场景下如果死锁检测本身成为性能瓶颈可以考虑把它关闭然后依赖innodb_lock_wait_timeout来兜底。但说实话这种情况非常罕见绝大数业务根本到不了那个并发量级贸然关闭死锁检测反而可能让死锁长时间占用连接。我的建议是没有经过严格压测论证不要关闭这个参数。4.3 事务大小与持锁时间对锁竞争的影响锁竞争的本质是“多个事务同时想访问同一批资源”而事务的大小和持锁时间直接决定了竞争窗口的大小。一个事务里执行10条SQL和100条SQL前者持锁时间通常远小于后者一个包含用户交互的长事务如果在里面开了事务后去调远程接口持锁时间可能长达几百毫秒甚至几秒这段时间内所有需要访问相同数据的事务都被堵住了。有一类非常典型的线上锁等待问题是代码里事务内嵌了外部调用BEGIN- 更新订单状态 - 调用支付回调接口 - 更新其他表 -COMMIT。如果回调接口响应慢整个事务就一直持有订单行的锁任何对这个订单的操作全部排队。这个问题在代码Review阶段就必须拦截。事务里绝对不能有网络IO这是我在很多次事故复盘后总结出来的一条铁律。把事务拆小是减少锁竞争最有效的手段之一。我见过有些同事习惯把一大坨写操作塞进一个事务里理由是怕数据不一致其实只要拆分合理配合幂等设计一致性完全可以通过补偿机制来保证而锁竞争和死锁的概率能下降一个数量级。事务短小永远是对的事务越长持锁越久风险越高。5. 减少死锁的实战优化手段5.1 统一索引访问路径与更新顺序所有业务SQL在更新数据时尽量走同一个索引这是我从实践中总结出的减少死锁的第一守则。原理很简单行锁挂在索引记录上如果两个事务对同一行数据使用不同的索引来定位那么它们加锁的顺序、加锁的区间就不一致很容易出现交叉等待。举个例子订单表上有主键id、订单号order_no、用户id user_id三个索引。事务1用WHERE id100去更新一行事务2用WHERE order_noABC100去更新同一行看起来都能命中同一行数据但加锁时一个直接锁主键索引记录另一个先走二级索引拿到主键值再回表锁主键记录加锁路径不同配合其他语句就可能产生意想不到的等待关系。所以业务里定位同一行数据时尽量统一用同一个字段。更新顺序的问题前面已经讲过这里再强化一下同一事务里涉及多行数据更新务必按主键或者某个业务唯一键排序后统一顺序执行。这个规则不只在单表内有效跨表更新也一样事务1先更新A表再更新B表事务2也应该先更新A表再更新B表。只要全局所有事务都遵守同一套访问顺序循环等待这个必要条件就被破坏了死锁自然消失。5.2 缩小锁定范围与合理设计索引锁的范围越大冲突概率越高这是一个数学上的必然。缩小锁定范围可以从两个方向入手一是让UPDATE或DELETE语句尽可能走索引避免全表扫描导致的行锁“伪表锁”效果二是让扫描的区间尽可能小用更精确的WHERE条件。InnoDB的行锁机制依赖索引来实现如果没有索引可用InnoDB只能全表扫描来定位目标行每扫到一行就会对这行加锁。表面上看你只是想更新一行数据实际整个表的行都被锁过了虽然最终只持有一部分锁但扫描过程中产生的其他行锁会阻塞其他事务对这些行的操作触发大量锁等待和死锁。经典的优化手段是在WHERE条件涉及的字段上建立合适的联合索引让更新语句的锁定范围精确收缩。我处理过这样一个问题某表daily_report按日期字段更新当天报表数据但日期字段没有索引UPDATE语句每次全表扫描多个批次并发执行时频繁死锁。后来在日期字段上加了一个普通索引死锁数量直接降到了接近零。这个案例非常典型SQL本身没变就是路径变了结果天差地别。5.3 隔离级别选择RR与RC的本质差异隔离级别对锁行为的影响非常大尤其在间隙锁问题上。默认的RR隔离级别会启用临键锁和间隙锁来防止幻读而RC隔离级别只用记录锁不控制间隙所以死锁概率显著降低代价是会出现不可重复读和幻读的可能。我在很多业务团队里看到的现象是大家用了好几年MySQL但从来没人去思考过“系统到底需不需要RR”。对于多数OLTP业务来说RC完全够用而且收益很明显锁粒度更小并发度更高死锁发生频率大幅下降。特别是那些以UPDATE为主、对幻读不敏感的业务切到RC之后效果立竿见影。切隔离级别要谨慎的一点是如果业务代码里存在依赖“同一事务内两次SELECT结果一致”的逻辑比如先查余额再扣款、先查库存再下单这类操作切到RC后就需要引入额外的行锁例如SELECT ... FOR UPDATE来保护逻辑否则数据一致性可能出问题。改隔离级别不是简单的参数变更得跟着Review一遍业务逻辑。5.4 应用层重试与降级策略不管你把优化做得多么到位死锁在极端并发下依然可能发生因为数据库层面无法完全消除共享资源的争用。所以应用层的兜底策略——捕获死锁异常并重试——是必须的。我在代码规范里一般要求所有写操作都加上死锁重试逻辑重试次数建议3次每次重试间隔可以非常短几十毫秒即可。这里有一个容易踩的坑重试整个事务时如果事务内某些操作不是幂等的就会造成重复更新或者重复插入。比如事务里有INSERT语句重试时如果没有唯一键约束做保护就可能插出两条数据。所以设计重试方案时必须考虑幂等性——要么保证事务内有天然的幂等键要么在事务外先做好去重。除了重试还有更高级一点的降级策略当死锁频繁发生时可以在应用层做并发限流比如按订单号或用户ID哈希后分桶同一桶内的操作串行执行。这个方法相当于把数据库层面的并发竞争提前到应用层解决虽然牺牲了一点吞吐但换来了极强的稳定性。对于核心交易链路我倾向于用这种偏保守的方案稳比快重要得多。6. 独家避坑经验与高频问题速查6.1 容易忽略的死锁触发点有几个死锁诱因是那种平时不起眼、一旦出事就非常难查的。第一个是INSERT ... ON DUPLICATE KEY UPDATE很多人觉得这就是一条语句应该不会锁冲突其实它在唯一键冲突时会对冲突记录加X锁并发插入同一条记录时同样会死锁。第二个是外键约束子表插入时会对父表记录加S锁多个事务插入引用同一父记录的子记录时S锁之间本来兼容但配合后续更新就可能升级成复杂等待。第三个是ALTER TABLE造成元数据锁MDL阻塞。元数据锁不在InnoDB存储引擎层而是在MySQL Server层但它能让所有DML语句全部排队。很多时候线上出现大面积锁等待排查半天发现不是行锁问题而是一个DDL操作把整张表的读写全堵住了。查锁等待的时候一定要顺手看一眼是否有Waiting for table metadata lock状态的会话。第四个隐藏触发点是一致性读与当前读混合使用。事务里先做普通的SELECT快照读再做UPDATE当前读如果数据在两步之间被其他事务修改了就会触发锁的获取和等待配合其他事务的操作也容易产生死锁。这种场景表面上看不太出来因为两条语句根本没有明显的锁冲突但加上间隙锁后就全变了。6.2 如何快速判断是死锁还是单纯阻塞这是个非常实际的问题因为两个场景的报错信息不一样处理方式也不一样搞混了会浪费大量时间。死锁的报错是Deadlock found when trying to get lock; try restarting transaction这个错误发生得非常快几乎不需要等50秒。单纯的锁阻塞报的是Lock wait timeout exceeded; try restarting transaction它是等满了超时时间之后才抛出的。判断方法除了看报错文案还能看时间线。如果一个操作立刻报死锁错误说明InnoDB的死锁检测直接发现了循环等待如果一个操作卡了几秒甚至几十秒后报超时说明是单纯的锁等待背后一定有个长事务持锁不释放。拿到这个判断之后处理手段截然不同死锁要查SQL顺序、索引、锁区间阻塞要查长事务、连接池、事务内的外部调用。我在团队里经常给新同学开小灶讲这个区分方法。有一次线上告警开发同学一口咬定是死锁结果我一看错误日志全是Lock wait timeout顺着阻塞链找下去发现是一个后台跑批任务开着事务批量更新中间还睡了好几秒把整张表的更新操作都堵住了。方向不对排查再久也徒劳。6.3 一个解决死锁问题的通用排查清单长期处理死锁问题之后我总结了一个排查清单遇到死锁直接照着走通常不需要太久就能定位到根因先确认报错类型是Deadlock found还是Lock wait timeout这两者的处理方向完全不同。执行SHOW ENGINE INNODB STATUS\G取出LATEST DETECTED DEADLOCK部分翻译出两个事务的持有锁和等待锁。拉出两个事务的完整业务代码上下文重点看事务体内所有SQL的执行顺序特别是每条SQL走的索引。用系统表查当前是否存在其他锁等待事务排除“已经恢复正常日志只是历史记录”的情况。检查索引使用情况确认UPDATE和DELETE语句是否命中合适索引锁定范围是否远比业务所需更大。确认隔离级别是否高于业务实际需求评估是否可以从RR降到RC。检查事务体内是否包含外部调用、大循环、批量操作等延长持锁时间的代码。在所有写操作入口加上死锁重试逻辑并确保重试不会破坏幂等性。这份清单我几乎是每个月都会用到一次。实际上线的时候大多数死锁问题走到第5步也就定位到了走到第7步的往往是那种跟锁关系不大但制造了锁竞争的长事务问题。把这份清单交给团队后端同学让他们排查死锁时有个标准动作比自己挨个去救火要高效得多。6.4 生产环境死锁案例复盘与思考最后分享一个我自己处理过的案例完整走一遍排查闭环。某天线上核心服务突然告警增多日志里大量死锁错误涉及两张表用户账户表account和账户流水表account_log。业务逻辑是事务内先往account_log插入一条流水再更新account表的余额字段。刚开始所有人都很困惑因为从逻辑上看插入流水是往一张表加记录更新余额是改另一张表的行各自独立怎么会死锁我把死锁日志拉出来一翻译发现事务1持有account表中某行的锁在等account_log表的插入意向锁事务2持有account_log表的插入意向锁在等account表中同一行的锁。两条锁等待路径直接形成一个闭环死锁成立。停顿了一下问了开发同学一个问题这两条SQL是不是反过来了开发确认事务1是先插流水再改余额事务2是先改余额再插流水。两个事务对两张表的访问顺序不一致和AB-BA死锁的底层逻辑一模一样只是跨表了而已。解决方案也很简单——统一所有事务对这两张表的操作顺序全部改成先改account再插account_log。上线后死锁消失一个告警都没再出现过。这个案例我经常拿来给团队讲因为它说明了一个核心道理死锁的根源往往不是数据库而是业务代码对共享资源的访问顺序不一致。锁机制只是把这个问题暴露出来真正修复它的地方在业务代码里。理解这一点比背一百条死锁报错处理办法都有用。个人经验之谈排查死锁这么多年我最深的体会是死锁问题没有那么多“高深莫测”绝大部分都是访问顺序问题、索引路径问题、事务大小问题这三类。把这三类问题在设计和Review阶段就控制住线上遇到死锁的概率能降低八成以上。真等到死在日志里跟你打招呼再做优化代价就大了。