Mysql

关注公众号 jb51net

关闭
首页 > 数据库 > Mysql > mysql死锁排查

MySQL死锁排查指南

作者：不如打代码KK

本文详细介绍了MySQL死锁的排查与解决方法,从死锁的定义、Java业务中的死锁场景、死锁排查步骤和命令到根治死锁的方案,包括约定统一的加锁顺序、缩短事务范围和优化数据库层面,提供了全面的指导,感兴趣的朋友跟随小编一起看看吧

MySQL死锁排查指南

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

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

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

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

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

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

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

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

当两个事务同时执行时：

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

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

步骤1：查看死锁日志

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

SHOW ENGINE INNODB STATUS;

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

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

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

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

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

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

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

@Service
public class TransferService {
    @Autowired
    private AccountMapper accountMapper;
    // 统一的转账方法（无论谁转谁，都按ID大小顺序加锁）
    @Transactional
    public void transfer(String fromId, String toId, int amount) {
        // 步骤1：确定加锁顺序（全局统一规则）
        String lockFirstId; // 先锁这个ID
        String lockSecondId; // 后锁这个ID
        if (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）。

流程展示

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

时间线事务1（A转B：先锁A，再锁B）事务2（B转A：先锁B，再锁A）状态
T1执行 deductBalance("user_001", 10)，成功锁定 user_001-事务1持有A的锁
T2-执行 deductBalance("user_002", 20)，成功锁定 user_002事务2持有B的锁
T3尝试执行 addBalance("user_002", 10)，需要锁B → 等待-事务1等待B的锁
T4-尝试执行 addBalance("user_001", 20)，需要锁A → 等待事务2等待A的锁
T5持续等待B的锁持续等待A的锁死锁

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

时间线事务1（A转B：先锁A，再锁B）事务2（B转A：先锁A，再锁B）状态
T1执行 deductBalance("user_001", 10)，成功锁定 user_001-事务1持有A的锁
T2-尝试执行 addBalance("user_001", 20)，需要锁A → 等待事务2等待A的锁
T3执行 addBalance("user_002", 10)，成功锁定 user_002-事务1持有A、B的锁
T4事务执行完成，释放A、B的锁-事务1提交，锁释放
T5-获得A的锁，执行 addBalance("user_001", 20)事务2持有A的锁
T6-执行 deductBalance("user_002", 20)，成功锁定 user_002事务2持有A、B的锁
T7-事务执行完成，释放A、B的锁事务2提交，无死锁

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

方案2：缩短事务范围

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

// 坏例子：事务包含RPC调用（加长锁持有时间）
@Transactional
public void badTransfer(String fromId, String toId, int amount) {
    accountMapper.updateBalance(fromId, -amount);
    rpcClient.notifyThirdParty(fromId, toId, amount); // 非DB操作，加长事务
    accountMapper.updateBalance(toId, +amount);
}
// 好例子：事务仅包含DB操作
@Transactional
public void goodTransfer(String fromId, String toId, int amount) {
    accountMapper.updateBalance(fromId, -amount);
    accountMapper.updateBalance(toId, +amount);
}
// 非DB操作放在事务外
public void transferWithNotify(String fromId, String toId, int amount) {
    goodTransfer(fromId, toId, amount);
    rpcClient.notifyThirdParty(fromId, toId, amount);
}

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

到此这篇关于MySQL死锁排查指南的文章就介绍到这了,更多相关mysql死锁排查内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文