摘要：“用户下单全卡死了！客服电话被打爆！” 同时电话铃声响起，我揉了揉惺忪的睡眼，打开监控系统——数据库CPU飙到90%，活跃线程数突破天际，日志里赫然躺着几个大字：Deadlock found。
凌晨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;⚠️ 关键点：锁的顺序不一致是死锁的导火索。
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应用死锁时，用以下命令捕获线程堆栈：Bashjstack -l > deadlock.log若发现类似“Thread-1 waiting on ”的提示，说明代码存在锁竞争。
1. 紧急止血：手动Kill事务
SQL-- 查询阻塞进程 SELECT * FROM infORMation_schema.INNODB_TRX; -- 终止指定事务（MySQL） KILL ; -- PostgreSQL用pg_terminate_backend SELECT pg_terminate_backend();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实现分布式锁，避免跨节点死锁：
JavaRLock lock = redisson.getLock("orderLock"); lock.lock(10, TimeUnit.SECONDS); // 自动续期，防止超时 try { // 业务逻辑 } finally { lock.unlock; }注意：Redis锁需配合Lua脚本保证原子性。
案例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批量插入未用拼接，而是逐条插入，产生大量行锁。优化方案：改用INSERT INTO ... VALUES (...), (...)批量提交。
死锁如同程序世界的“交通事故”，无法完全避免，但可以通过规范驾驶（代码规范）、安装雷达（监控工具）和制定应急流程（排查手册）将损失降到最低。
最后送大家一句话：锁用得好，系统稳如狗；锁用不好，半夜运维吼。
来源：电脑技术汇
