今天聊一个让我半夜爬起来好几次的话题：数据库死锁。

前阵子有个读者跟我描述了一个场景：某个电商大促期间，订单系统突然大面积报 

，业务方快疯了。他赶紧执行了 

 下面一大段日志，每个字母都认识，串起来完全看不懂。CPU 一度飙到 70%，所有 update/insert 都在排队等锁释放。

死锁的可怕之处在于：系统内有 4 万毫秒的强制锁释放超时设置，这意味着单个锁的等待最多 40 秒。一旦上万个请求同时堆积，不仅是数据库，整个应用层在 40 秒内都会体验断崖式响应延迟。如果是核心交易系统，用户看到的就是白屏和“网络异常”。

死锁，是指两个或多个事务在执行过程中，因争夺同一资源而互相等待，结果谁也无法继续执行，形成一个循环等待的僵局。事务 A 拿着资源 1 在等资源 2，事务 B 拿着资源 2 在等资源 1，谁也等不到，最后只能被数据库内核强制中止其中一个。死锁通常发生在使用 InnoDB 行锁且并发较高的事务中。

要让死锁发生，必须同时满足四个条件：

理论上打破其中任何一个，死锁就不会发生。但在高并发业务中，这四者几乎会同时出现。

InnoDB 默认死锁检测是开启的。一旦检测到死锁，会自动回滚其中一个事务（通常选择执行成本较小或持有锁较少的事务来作为牺牲者），另一个事务继续执行。这就是为什么 

 错误往往是偶发性的——有时候死锁触发了，其中一个事务被回滚，报错出现；有时候刚好绕过去了，业务不受影响。但如果业务本身对事务提交失败没有重试机制，每一次死锁都是一个定时炸弹。

我第一次看到这个命令的输出，满屏的十六进制地址、锁结构体，完全看不懂。后来在线上一遍遍对日志、查文档，才慢慢啃下来。今天把精华拆给你看。

 返回的内容很长，只会有一次最近的死锁记录（如果发生过多次，也只会保存最后一次），所以运维上建议开启 

，把所有死锁日志记录进错误日志，方便长期追踪。

下面是一个典型死锁日志的核心结构拆解：

------------------------
LATEST DETECTED DEADLOCK
------------------------
2026-01-15 14:23:45 0x7f8a2c001700
*** (1) TRANSACTION:
TRANSACTION 310298, ACTIVE 0 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 12345, OS thread handle 14000, query id 67890 10.0.0.1 app_user updating
UPDATE orders SET status = 'PAID' WHERE order_id = 10086
*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 100 page no 3 n bits 72 index PRIMARY of table `db`.`orders` 
trx id 310298 lock_mode X locks rec but not gap
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 100 page no 5 n bits 72 index idx_status of table `db`.`orders` 
trx id 310298 lock_mode X locks gap before rec insert intention waiting
*** (2) TRANSACTION:
TRANSACTION 310299, ACTIVE 0 sec fetching rows
...
*** (2) HOLDS THE LOCK(S):
...
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
...
*** WE ROLL BACK TRANSACTION (1)
​

从 MySQL 8.0 开始，官方推荐使用 Performance Schema 来更精细地监控锁竞争：

-- 查看当前所有锁信息
SELECT * FROM performance_schema.data_locks;

-- 查看当前锁等待关系
SELECT * FROM performance_schema.data_lock_waits;

-- 结合当前事务状态一起分析
SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id 
FROM information_schema.INNODB_TRX 
WHERE trx_state = 'LOCK WAIT';
​

这些视图能看到死锁发生前实际的阻塞链条，比 

1. 多表访问顺序不一致（最常见）

。解法：统一规定业务代码中的访问顺序，按表名或主键 ID 升序访问。

SQL 执行计划异常导致全表扫描，一次性锁了大量行。解法：在 WHERE 条件上建立合适的索引，缩小扫描范围。

RR 隔离级别下，InnoDB 会锁住间隙防止幻读，多个事务同时插入时可能互相等待。解法：考虑降级为 

 隔离级别（RC 模式无间隙锁），同时 binlog 格式设置为 ROW。

更新主表时不仅要锁本表，还要检查关联子表，高并发下容易死锁。

我是运营转行做的 DBA。早期处理故障时，总习惯先看监控大盘、重启应用、发公告——这是运营的“止血思维”。后来被线上问题教育了几次才明白，DBA 得反过来：先看锁日志、定位具体 SQL、再决定怎么处理。盲目重启只是掩盖问题，过不了多久还会再崩。这个思维转换，比学会任何一条命令都重要。

 确认死锁及涉及 SQL，然后分析锁等待链，找出形成循环的两个事务，接着排查索引是否生效、是否存在全表扫描，最后从代码层面统一访问顺序、拆分长事务、完善重试。

死锁不是玄学，它是数据库并发控制的必然产物。理解它、排查它，是 DBA 和普通开发的分水岭。

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~

前阵子有个读者跟我描述了一个场景：某个电商大促期间，订单系统突然大面积报 Deadlock found，业务方快疯了。他赶紧执行了 SHOW ENGINE INNODB STATUS，看到 LATEST DETECTED DEADLOCK 下面一大段日志，每个字母都认识，串起来完全看不懂。CPU 一度飙到 70%，所有 update/insert 都在排队等锁释放。

别再被死锁坑了！3个最常见的死锁场景及一键避坑清单

详解MySQL死锁：本质是事务循环等待资源，InnoDB自动回滚牺牲者。通过`SHOW ENGINE INNODB STATUS`定位锁链，结合索引优化、统一加锁顺序、降隔离级（RC）、加重试等手段可有效防控。死锁非故障，而是高并发下的必然现象。

数据库

数据库死锁是指多个事务因争夺资源导致的循环等待僵局。本文结合实际案例详细解析SHOW ENGINE INNODB STATUS死锁日志，分析InnoDB死锁检测机制与四个必要条件。揭露间隙锁、批量更新等常见死锁场景，提供统一加锁顺序、拆分长事务、优化索引等具体解决方案。帮助开发者掌握从日志分析到代码优化的完整死锁排查方法，提升数据库高并发稳定性。

MySQL

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


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

数据库死锁是指多个事务因争夺资源导致的循环等待僵局。本文结合实际案例详细解析SHOW ENGINE INNODB STATUS死锁日志，分析InnoDB死锁检测机制与四个必要条件。揭露间隙锁、批量更新等常见死锁场景，提供统一加锁顺序、拆分长事务、优化索引等具体解决方案。帮助开发者掌握从日志分析到代码优化的完整死锁排查方...

别再被死锁坑了！3个最常见的死锁场景及一键避坑清单

别再被死锁坑了！3个最常见的死锁场景及一键避坑清单

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐