MySQL死锁排查指南

MySQL死锁排查指南

作为一名10年经验的Java工程师，我会从场景、排查、解决三个维度，带你搞定MySQL死锁问题。

一、先搞懂：死锁是什么？

死锁是多个事务互相持有对方需要的资源，陷入无限等待的僵局。

它必须同时满足4个“缺一不可”的条件（破坏任意一个就能避免死锁）：

1. 资源独占：一个资源（如一行数据）只能被一个事务持有；
2. 请求并持有：事务持有资源的同时，又请求其他资源且不释放已有资源；
3. 不可剥夺：事务已获得的资源不能被强行抢占；
4. 循环等待：事务之间形成“事务A等B，B等A”的闭环。

二、经典场景：Java业务里的死锁长啥样？

以用户互转余额为例（Java+MySQL事务）：

// 事务A：用户A给B转账10元@TransactionalpublicvoidtransferAtoB(StringaId,StringbId,intamount){// 1. 锁定A的账户（更新操作会加行锁）accountMapper.updateBalance(aId,-amount);// 2. 尝试锁定B的账户（若B此时正在操作A，就会等待）accountMapper.updateBalance(bId,+amount);}// 事务B：用户B给A转账20元@TransactionalpublicvoidtransferBtoA(StringbId,StringaId,intamount){// 1. 锁定B的账户accountMapper.updateBalance(bId,-amount);// 2. 尝试锁定A的账户（此时A已被事务A锁定，陷入等待）accountMapper.updateBalance(aId,+amount);}

当两个事务同时执行时：

• 事务A持有A的锁，等待B的锁；
• 事务B持有B的锁，等待A的锁；
  → 死锁产生。

三、死锁排查：核心步骤+命令

当业务出现“接口超时、事务卡住”时，优先排查死锁。

步骤1：查看死锁日志

MySQL（InnoDB引擎）最核心的排查命令：

SHOWENGINEINNODBSTATUS;

执行后，找到LATEST DETECTED DEADLOCK模块，关键信息包括：

• TRANSACTION (1)/(2)：冲突的两个事务；
• WAITING FOR THIS LOCK：事务等待的锁及对应的SQL；
• HOLDS THE LOCK(S)：事务持有的锁及对应的SQL；
• WE ROLL BACK TRANSACTION (X)：MySQL自动回滚的事务（解决死锁）。

步骤2：结合Java业务定位代码

根据死锁日志里的SQL语句，找到对应的Java代码（比如上述transferAtoB方法），分析事务的加锁顺序是否不一致。

四、根治死锁：Java业务里的落地方案

针对Java业务，从代码、数据库两个层面解决：

方案1：约定统一的加锁顺序（最有效）

我们约定一个全局规则：无论转账方向如何，都先锁定 ID 字典序更小的账户，再锁定 ID 更大的账户，这就是 “统一的加锁顺序”：

@ServicepublicclassTransferService{@AutowiredprivateAccountMapperaccountMapper;// 统一的转账方法（无论谁转谁，都按ID大小顺序加锁）@Transactionalpublicvoidtransfer(StringfromId,StringtoId,intamount){// 步骤1：确定加锁顺序（全局统一规则）StringlockFirstId;// 先锁这个IDStringlockSecondId;// 后锁这个IDif(fromId.compareTo(toId)<0){lockFirstId=fromId;lockSecondId=toId;}else{lockFirstId=toId;lockSecondId=fromId;}// 步骤2：按统一顺序加锁（先锁小ID，再锁大ID）// 先锁定第一个账户（无论它是转出方还是转入方）if(lockFirstId.equals(fromId)){accountMapper.deductBalance(lockFirstId,amount);// 转出}else{accountMapper.addBalance(lockFirstId,amount);// 转入}// 再锁定第二个账户if(lockSecondId.equals(fromId)){accountMapper.deductBalance(lockSecondId,amount);// 转出}else{accountMapper.addBalance(lockSecondId,amount);// 转入}}}

假设：A 的 ID 是user_001，B 的 ID 是user_002（user_001 < user_002）。

• 当调用transfer(“user_001”, “user_002”, 10)（A 转 B）：先锁user_001，再锁user_002；
• 当调用transfer(“user_002”, “user_001”, 20)（B 转 A）：依然先锁user_001，再锁user_002；
  两个事务的加锁顺序完全一致，不会出现 “你等我、我等你” 的循环等待，从根源上杜绝死锁。

流程展示

• 用户A：ID为user_001
• 用户B：ID为user_002
• 规则：user_001的字典序 <user_002

无统一加锁顺序 → 死锁（执行流程）
当两个事务各自按“转出方→转入方”的顺序加锁时：

有统一加锁顺序 → 无死锁（执行流程）
当两个事务都按“ID从小到大”的顺序加锁时：

这样是不是更清楚了？需要我把这个流程做成更简洁的对比表格方便你保存吗？

方案2：缩短事务范围

避免事务中包含非数据库操作（如RPC调用、日志打印），减少锁的持有时间：

// 坏例子：事务包含RPC调用（加长锁持有时间）@TransactionalpublicvoidbadTransfer(StringfromId,StringtoId,intamount){accountMapper.updateBalance(fromId,-amount);rpcClient.notifyThirdParty(fromId,toId,amount);// 非DB操作，加长事务accountMapper.updateBalance(toId,+amount);}// 好例子：事务仅包含DB操作@TransactionalpublicvoidgoodTransfer(StringfromId,StringtoId,intamount){accountMapper.updateBalance(fromId,-amount);accountMapper.updateBalance(toId,+amount);}// 非DB操作放在事务外publicvoidtransferWithNotify(StringfromId,StringtoId,intamount){goodTransfer(fromId,toId,amount);rpcClient.notifyThirdParty(fromId,toId,amount);}

方案3：优化数据库层面(按需)

• 加索引：确保更新/查询的WHERE条件走索引，减少锁的范围（避免表锁）；
• 降低隔离级别：业务允许的话，将隔离级别从REPEATABLE-READ（默认）降为READ-COMMITTED，减少间隙锁；
• 显式加锁优化：使用SELECT ... FOR UPDATE显式加锁时，确保WHERE条件走索引。