MySQL死锁排查指南

 更新时间:2025年12月26日 15:54:51   作者:不如打代码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);
}

当两个事务同时执行时:

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

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

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

步骤1:查看死锁日志

MySQL(InnoDB引擎)最核心的排查命令:

SHOW ENGINE INNODB STATUS;

执行后,找到 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 更大的账户,这就是 “统一的加锁顺序”:

@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)。

  • 当调用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

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

时间线事务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:优化数据库层面(按需)

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

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

相关文章

  • MySQL数据库中UUID主键性能优化的方案详解

    MySQL数据库中UUID主键性能优化的方案详解

    最近我们在性能优化中发现了一个隐蔽的问题,数据库的写入和查询性能在数据量增长后出现明显下降,原因竟然是UUID,本文将剖析UUID在数据库中的真实影响并提供更优化的解决方案,希望对大家有所帮助
    2026-02-02
  • Win10下免安装版MySQL8.0.16的安装和配置教程图解

    Win10下免安装版MySQL8.0.16的安装和配置教程图解

    这篇文章主要介绍了Win10下免安装版MySQL8.0.16的安装和配置 ,本文通过图文并茂的形式给大家介绍的非常详细,具有一定的参考解决价值,需要的朋友可以参考下
    2019-06-06
  • 查找MySQL中查询慢的SQL语句方法

    查找MySQL中查询慢的SQL语句方法

    这篇文章主要介绍了查找MySQL中查询慢的SQL语句方法,需要的朋友可以参考下
    2017-05-05
  • MySQL新手入门指南--快速参考

    MySQL新手入门指南--快速参考

    MySQL新手入门指南--快速参考...
    2006-11-11
  • MySQL中时区参数time_zone解读

    MySQL中时区参数time_zone解读

    MySQL时区参数time_zone用于控制系统函数和字段的DEFAULT CURRENT_TIMESTAMP属性,修改时区可能会影响timestamp类型的值,建议在MySQL配置文件中设置时区参数,以确保高并发时的性能,在业务中尽量使用datetime类型来存储时间,因为其时间上限比TIMESTAMP更远
    2025-01-01
  • mysql中的日期相减的天数函数

    mysql中的日期相减的天数函数

    这篇文章主要介绍了mysql中的日期相减的天数函数,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2023-02-02
  • MySQL root用户连接错误的三种解决方法

    MySQL root用户连接错误的三种解决方法

    本文提供了三种解决MySQL root密码错误的方案,方法一最可靠,通过创建初始化文件重置密码;方法二完全重新初始化数据目录,会生成临时密码;方法三建议查看错误日志,需要的朋友可以参考下
    2025-11-11
  • Mysql中的count()与sum()区别详细介绍

    Mysql中的count()与sum()区别详细介绍

    本文将介绍Mysql中的count()与sum()区别,需要的朋友可以参考下
    2012-11-11
  • mysql id从1开始自增 快速解决id不连续的问题

    mysql id从1开始自增 快速解决id不连续的问题

    这篇文章主要介绍了mysql id从1开始自增 快速解决id不连续的问题,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2021-07-07
  • MYSQL数据库连接池及常见参数调优方式

    MYSQL数据库连接池及常见参数调优方式

    这篇文章主要介绍了MYSQL数据库连接池及常见参数调优方式,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2023-06-06

最新评论