MySQL 死锁排查实战：从现象定位到固定加锁顺序

MySQL 死锁不是“数据库坏了”，而是两个事务互相等待对方已经持有的锁，谁也走不下去。InnoDB 会检测到这种环形等待，然后回滚其中一个事务，让另一个事务继续完成。

真正麻烦的是：死锁往往不是每次都出现，测试环境很难复现，线上日志里只看到一句 Deadlock found when trying to get lock。本文用一个转账场景，梳理从复现、定位到修复的完整流程。

摘要

本文会用账户余额表复现一次典型死锁：事务 A 先锁账户 1 再锁账户 2，事务 B 先锁账户 2 再锁账户 1。随后通过 SHOW ENGINE INNODB STATUS 查看死锁信息，最后用固定加锁顺序、缩短事务和有限重试来降低线上风险。

适合人群

适合正在维护 MySQL 事务代码、支付转账、库存扣减、订单状态流转和并发更新逻辑的开发者。你需要了解基础 SQL、事务和 SELECT ... FOR UPDATE 的含义。

目录

1. 先复现一个转账死锁
2. 用 SHOW ENGINE 查看死锁线索
3. 为什么反向加锁容易死锁
4. 修复一：固定加锁顺序
5. 修复二：缩短事务时间
6. 修复三：失败后有限重试
7. 排查清单和总结

一、先复现一个转账死锁

准备一张账户表：

CREATE TABLE account_balance (
  account_id BIGINT PRIMARY KEY,
  balance DECIMAL(12, 2) NOT NULL
) ENGINE=InnoDB;

INSERT INTO account_balance(account_id, balance)
VALUES (1, 1000.00), (2, 1000.00);

事务 A 先锁账户 1，再锁账户 2：

-- session A
START TRANSACTION;
SELECT * FROM account_balance WHERE account_id = 1 FOR UPDATE;
-- 等一会儿，再请求账户 2
SELECT * FROM account_balance WHERE account_id = 2 FOR UPDATE;

事务 B 先锁账户 2，再锁账户 1：

-- session B
START TRANSACTION;
SELECT * FROM account_balance WHERE account_id = 2 FOR UPDATE;
-- 等一会儿，再请求账户 1
SELECT * FROM account_balance WHERE account_id = 1 FOR UPDATE;

当两个事务交叉运行时，A 拿着账户 1 的锁等账户 2，B 拿着账户 2 的锁等账户 1，就形成了环形等待。

二、用 SHOW ENGINE 查看死锁线索

出现死锁后，可以在数据库里查看最近一次 InnoDB 死锁信息：

SHOW ENGINE INNODB STATUS\G

重点看三类信息：

• 哪个事务在等待锁。
• 它正在等待哪张表、哪个索引、哪条记录。
• 另一个事务已经持有什么锁。

不要只盯着错误日志里的 SQL 片段。死锁分析要把两个事务的锁顺序拼起来看，才能知道是谁先拿了哪把锁，又在等待哪把锁。

三、为什么反向加锁容易死锁

死锁的核心不是“有锁”，而是“多个事务拿锁顺序不一致”。转账业务里，A 是从 1 转到 2，B 是从 2 转到 1。如果代码按业务入参顺序加锁，就会出现反向路径。

事务 A：锁账户 1 -> 等账户 2
事务 B：锁账户 2 -> 等账户 1

如果两个事务都按账户 ID 从小到大加锁，就不会形成这种互相等待：

事务 A：锁账户 1 -> 锁账户 2
事务 B：等账户 1 -> 再锁账户 2

四、修复一：固定加锁顺序

修复转账类死锁，最常见的方式是固定加锁顺序。无论是从 1 转到 2，还是从 2 转到 1，都先锁较小的账户 ID，再锁较大的账户 ID。

START TRANSACTION;

SELECT * FROM account_balance
WHERE account_id IN (1, 2)
ORDER BY account_id
FOR UPDATE;

UPDATE account_balance
SET balance = balance - 100
WHERE account_id = 1;

UPDATE account_balance
SET balance = balance + 100
WHERE account_id = 2;

COMMIT;

这样做的目的不是让锁消失，而是让所有事务排队使用同一条路。等待仍然可能发生，但环形等待会少很多。

五、修复二：缩短事务时间

事务里只放必须保持一致的数据库操作。不要在事务中做远程接口调用、复杂计算、文件处理或人工等待。

推荐结构是：

1. 事务前完成参数检查和外部状态准备。
2. 事务内只读取需要加锁的数据并更新。
3. 提交后再发送消息、刷新缓存或写非关键日志。

事务越短，锁持有时间越短，并发冲突窗口也越小。

六、修复三：失败后有限重试

即使固定了锁顺序，也不能保证永远没有死锁。线上代码应该把死锁当作可恢复的并发失败，做有限次数重试。

getMessage();
            $isDeadlock = str_contains($message, 'Deadlock found');
            if (!$isDeadlock || $attempt === $maxAttempts) {
                throw $e;
            }
            usleep(50_000 * $attempt);
        }
    }
}

重试要有限，且最好带一点退避时间。不要无限循环，否则数据库压力高时会把问题放大。

七、排查清单和总结

排查清单

• 用 SHOW ENGINE INNODB STATUS\G 找到最近一次死锁信息。
• 确认两个事务分别持有哪些锁、等待哪些锁。
• 检查业务代码是否按入参顺序加锁。
• 把多行加锁改成稳定顺序，例如按主键从小到大。
• 缩短事务，不在事务里做慢操作。
• 对可恢复的死锁错误做有限重试。

总结

MySQL 死锁排查的重点，是把“两个事务的锁顺序”还原出来。发现反向加锁后，优先统一加锁顺序；事务时间过长时，拆掉事务里的慢操作；线上代码再配合有限重试。这样处理后，死锁从偶发疑难问题变成可理解、可控制的并发失败。

参考资料

本文参考 MySQL 官方文档中关于 InnoDB 死锁、事务和锁等待排查的说明，示例为转账业务场景原创整理。