
## 一、什么是死锁（Deadlock）

**死锁**是指两个或多个事务在执行过程中，**相互持有对方所需的锁资源，且都无法继续执行**，从而形成永久等待的状态。

在 MySQL（InnoDB）中，一旦检测到死锁，**InnoDB 会主动回滚其中一个事务**，并返回错误：

```sql
ERROR 1213 (40001): Deadlock found when trying to get lock
```

⚠️ 死锁并不是 MySQL 的 bug，而是**高并发事务系统中不可避免的现象**。

---

## 二、MySQL 死锁产生的核心原因

### 1. 不同事务以不同顺序加锁（最常见）

```text
事务 A：锁住记录 1 → 等待记录 2
事务 B：锁住记录 2 → 等待记录 1
```

📌 **典型场景**

* 多表更新
* 同一表不同条件更新
* 批量更新 + 单条更新并发

---

### 2. 索引缺失或索引失效，导致“锁扩大”

```sql
UPDATE orders SET status = 1 WHERE user_id = 100;
```

如果 `user_id` **没有索引**：

* InnoDB 会进行 **全表扫描**
* 锁住大量行（甚至接近表锁）
* 与其他事务形成交叉锁

📌 这是**死锁的高发根因**

---

### 3. RR 隔离级别下的间隙锁（Gap Lock）

InnoDB 默认隔离级别是 **REPEATABLE READ**，会引入：

* Record Lock（记录锁）
* Gap Lock（间隙锁）
* Next-Key Lock（记录 + 间隙）

```sql
SELECT * FROM orders WHERE id BETWEEN 10 AND 20 FOR UPDATE;
```

📌 并发插入、更新区间数据时，**非常容易形成死锁**

---

### 4. 长事务 + 高并发

* 事务中包含：

  * 网络调用
  * 业务计算
  * sleep / 等待外部资源
* 导致锁长期不释放

📌 **长事务 = 死锁放大器**

---

### 5. 批量操作与单行操作并发

```text
事务 A：批量更新 1~1000
事务 B：更新单条 500
```

锁范围交叉 + 顺序不同 → 死锁

---

### 6. ORM 自动生成 SQL 不可控

如：

* GORM / MyBatis 自动拼 SQL
* where 条件顺序不一致
* 隐式事务

📌 在复杂系统中非常常见

---

## 三、死锁排查的标准步骤（实战）

### 第一步：确认是否真的发生死锁

查看应用日志：

```text
Deadlock found when trying to get lock; try restarting transaction
```

---

### 第二步：查看最近一次死锁信息（核心）

```sql
SHOW ENGINE INNODB STATUS\G
```

关注：

```text
LATEST DETECTED DEADLOCK
```

重点看：

* 涉及的 SQL
* 哪些索引
* 锁类型（X / S / GAP）
* 哪个事务被回滚

📌 **这是排查死锁最重要的一步**

---

### 第三步：查看当前锁等待情况

```sql
SELECT * FROM information_schema.INNODB_TRX;
SELECT * FROM information_schema.INNODB_LOCKS;
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
```

MySQL 8.0 可使用：

```sql
SELECT * FROM performance_schema.data_locks;
```

---

### 第四步：分析 SQL 是否合理

重点检查：

* 是否走了**正确索引**
* where 条件是否精确
* 是否使用了范围查询
* 是否存在 `FOR UPDATE` / `LOCK IN SHARE MODE`

```sql
EXPLAIN UPDATE ...
```

---

### 第五步：定位事务逻辑问题

问自己几个关键问题：

* 多个事务是否**加锁顺序一致**
* 是否存在不必要的事务
* 是否可以拆分事务
* 是否可以降低锁粒度

---

## 四、死锁的系统性解决方案

### 1. 统一加锁顺序（最有效）

❌ 错误：

```text
事务 A：先更新表 A → 表 B
事务 B：先更新表 B → 表 A
```

✅ 正确：

```text
所有事务：先 A → 再 B
```

📌 **这是预防死锁的第一原则**

---

### 2. 补齐 & 优化索引

* where 条件字段必须有索引
* 避免函数、隐式转换导致索引失效
* 联合索引顺序与查询条件一致

```sql
ALTER TABLE orders ADD INDEX idx_user_status(user_id, status);
```

---

### 3. 控制事务粒度与时长

* 事务中只放 **数据库操作**
* 不要在事务中：

  * 调接口
  * 做复杂计算
  * sleep

📌 **短事务是死锁的天然克星**

---

### 4. 减少范围锁 & 间隙锁

* 尽量使用 **等值查询**
* 能用主键就用主键
* 非必要不使用 `FOR UPDATE`

如允许：

```sql
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
```

📌 在 RC 下，**Gap Lock 会显著减少**

---

### 5. 拆分大事务 / 批量操作

❌ 一次更新 1 万条
✅ 分批 100 条提交

---

### 6. 业务层面增加重试机制（兜底）

InnoDB 会自动回滚一个事务
**合理的做法是：**

```text
捕获死锁异常 → 随机延迟 → 重试
```

📌 几乎所有成熟系统都会这样做

---

## 五、如何判断“死锁是否可接受”

✔️ **可接受的死锁**

* 偶发
* 自动重试成功
* 对业务无感知

❌ **不可接受的死锁**

* 高频出现
* 同一 SQL 重复死锁
* 导致大量事务失败

---

## 六、总结

> **死锁不是“要不要解决”的问题，而是“如何管理”的问题**

### 一句话总结

* 死锁 ≠ Bug，而是并发的必然结果
* 索引、事务、顺序 是三大关键点
* 排查靠 `SHOW ENGINE INNODB STATUS`
* 解决靠 **设计 + 规范 + 重试机制**




死锁是指两个或多个事务在执行过程中，相互持有对方所需的锁资源，且都无法继续执行，从而形成永久等待的状态。

MySQL 死锁问题：成因分析与排查解决全流程

MySQL 死锁源于并发事务锁顺序不一致、索引缺失和长事务。通过 InnoDB 状态分析、优化索引、统一加锁顺序、缩短事务并增加重试机制可有效解决。

架构师

数据库

后端

MySQL死锁是多个事务相互持有对方所需锁资源导致的永久等待状态。常见原因包括不同加锁顺序、索引缺失、间隙锁、长事务等。排查方法包括查看死锁日志、分析锁等待情况、优化SQL和事务设计。解决方案涉及统一加锁顺序、优化索引、控制事务粒度、减少范围锁及增加重试机制。死锁是并发系统的必然现象，需通过合理设计和管理来降低影响。

MySQL

腾讯云数据库特惠，新用户首单0.5折起


AI驱动 智领未来

tencentdb-catalog

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MySQL 死锁问题：成因分析与排查解决全流程-腾讯云开发者社区-腾讯云

MySQL 死锁问题：成因分析与排查解决全流程

MySQL 死锁问题：成因分析与排查解决全流程

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐