凌晨2点，运维群里发消息：“用户下单全卡死了！客服电话被打爆！” 同时电话铃声响起，我揉了揉惺忪的睡眼，打开监控系统——数据库CPU飙到90%，活跃线程数突破天际，日志里赫然躺着几个大字：Deadlock found。

这不是我第一次遇到死锁，但这次的问题却像一场“密室逃脱”游戏：订单表和库存表互相锁住对方，用户付了钱却看不到订单，商家库存扣减失败，整个系统陷入瘫痪。

为什么数据库会“同归于尽”？如何快速破局？ 这篇文章将用最“人话”还原我的排查实录。

死锁的“四宗罪”：它到底是怎么发生的？

1. 死锁的“作案条件” 数据库死锁就像两辆车在窄路上互不相让，必须同时满足四个条件才会发生：

• 互斥占有：订单表锁住资源A，库存表锁住资源B，互不相让；
• 请求等待：订单表还想抢库存表的B，库存表又想抢订单表的A；
• 不可剥夺：谁都不肯先放手；
• 环路等待：A等B，B等A，形成死循环。

2. 真实场景还原 假设用户A下单时先锁订单表再锁库存表，用户B调整库存时先锁库存表再锁订单表。当两人同时操作，死锁概率飙升！

SQL
-- 用户A的SQL  
BEGIN;  
UPDATE 订单表 SET status=1 WHERE id=100;  
UPDATE 库存表 SET stock=stock-1 WHERE product_id=200;  
COMMIT;  

-- 用户B的SQL  
BEGIN;  
UPDATE 库存表 SET stock=10 WHERE product_id=200;  
UPDATE 订单表 SET status=2 WHERE id=100;  
COMMIT;  

关键点：锁的顺序不一致是死锁的导火索。

排查工具包：3分钟锁定原因

1. 第一步：抓现行——死锁日志分析 MySQL用户请直奔错误日志：

Bash
# 查看最近死锁记录  
SHOW ENGINE INNODB STATUS\G  

输出中重点关注：

• LATEST DETECTED DEADLOCK：死锁事务ID、冲突的SQL；
• WAITING FOR THIS LOCK：线程在等哪个锁；
• HOLDS THE LOCK：当前持有哪些锁。

案例：某电商系统日志显示，两个事务分别通过idx_seller_transNo和主键索引互相阻塞，最终因索引设计缺陷导致环路等待。

2. 第二步：现场还原——监控工具实战

• Navicat Monitor：图形化展示锁等待链，一键定位“卡脖子”的SQL；
• pt-deadlock-logger：实时捕获死锁事件并记录到表中，适合长期监控；
• 某云DAS：自动分析SQL执行计划，揪出低效索引。

3. 第三步：代码层分析

• Jstack抓线程快照：Java应用死锁时，用以下命令捕获线程堆栈：

Bash
jstack -l <PID> > deadlock.log  

若发现类似“Thread-1 waiting on <0x000000071b2a1d98>”的提示，说明代码存在锁竞争。

绝地反击：5大救命方案

1. 紧急止血：手动Kill事务

SQL
-- 查询阻塞进程  
SELECT * FROM information_schema.INNODB_TRX;  

-- 终止指定事务（MySQL）  
KILL <trx_id>;  

-- PostgreSQL用pg_terminate_backend  
SELECT pg_terminate_backend(<PID>);  

2. 根治方案：从代码和SQL入手

• 统一锁顺序：所有事务按“订单表→库存表”顺序加锁；
• 短事务原则：避免一个事务包含多个耗时操作；
• 索引优化：为seller_id和fund_transfer_order_no字段添加覆盖索引，减少锁冲突；
• 启用乐观锁：通过版本号控制更新，避免SELECT FOR UPDATE。

3. 数据库层“防御工事”

• 设置死锁超时：

SQL
-- MySQL调整检测阈值（默认50秒）  
SET GLOBAL innodb_lock_wait_timeout=30;  

• 强制锁超时：在JDBC连接串中添加&lockWaitTimeout=30000；
• 拆解长事务：将大事务拆为小批次提交，降低锁持有时间。

4. 高级武器：分布式锁 在高并发场景下，用Redisson或Zookeeper实现分布式锁，避免跨节点死锁：

Java
RLock lock = redisson.getLock("orderLock");  
lock.lock(10, TimeUnit.SECONDS); // 自动续期，防止超时  
try {  
    // 业务逻辑  
} finally {  
    lock.unlock();  
}  

注意：Redis锁需配合Lua脚本保证原子性。

5. 防患于未然：监控告警体系

• Prometheus+Grafana：监控数据库锁等待时长、死锁次数；
• 日志告警：通过ELK捕获Deadlock found关键字，实时推送钉钉/企业微信。

那些年我踩过的坑

案例1：前缀索引引发的惨案 某支付系统因seller_id和fund_transfer_order_no(20)的前缀索引重复，导致两条不同订单的索引值相同，触发死锁。解决方案：将前缀长度改为50，并改用唯一索引。

案例2：JPA的“隐身锁” Spring Data JPA的@Transactional注解未指定隔离级别，导致默认的REPEATABLE_READ引发间隙锁冲突。修正方案：

Java
@Transactional(isolation = Isolation.READ_COMMITTED)  

案例3：ORM框架的“偷懒”操作 MyBatis批量插入未用<foreach>拼接，而是逐条插入，产生大量行锁。优化方案：改用INSERT INTO ... VALUES (...), (...)批量提交。

死锁如同程序世界的“交通事故”，无法完全避免，但可以通过规范驾驶（代码规范）、安装雷达（监控工具）和制定应急流程（排查手册）将损失降到最低。

最后送大家一句话：锁用得好，系统稳如狗；锁用不好，半夜运维吼。