SQL死锁产生场景分析_SQL实际案例讲解说明-SQL-PHP中文网

SQL死锁产生场景分析_SQL实际案例讲解说明

舞夢輝影

发布： 2025-12-23 17:28:44

原创

560人浏览过

SQL死锁是多个事务以不同顺序争夺同一组资源导致的循环等待现象，需满足互斥、请求保持、不可剥夺和循环等待四条件；InnoDB自动回滚改动少的事务，常见于交叉更新、间隙锁冲突及查后删/插等场景。

sql死锁产生场景分析_sql实际案例讲解说明

SQL死锁不是随机发生的异常，而是特定并发操作与加锁顺序共同作用的结果。核心在于“多个事务以不同顺序争夺同一组资源”，只要满足互斥、请求保持、不可剥夺和循环等待四个条件，死锁就可能触发。MySQL InnoDB 会自动检测并回滚一个事务（通常是改动行数更少的），但频繁死锁会影响业务稳定性。

常见死锁场景：交叉更新（AB-BA）

这是最典型、最容易复现的死锁模式。

事务A先更新id=1，再尝试更新id=2；
事务B先更新id=2，再尝试更新id=1；
当A持有id=1的排他锁、B持有id=2的排他锁时，双方都在等对方释放锁——循环等待形成。

例如：

T1: BEGIN; UPDATE users SET balance=100 WHERE id=1;
T2: BEGIN; UPDATE users SET balance=200 WHERE id=2;
T1: UPDATE users SET balance=150 WHERE id=2; → 等待T2释放id=2锁
T2: UPDATE users SET balance=250 WHERE id=1; → 等待T1释放id=1锁 → 死锁触发

容易被忽略的死锁：间隙锁 + 唯一索引冲突

在RR隔离级别下，INSERT … ON DUPLICATE KEY UPDATE 或唯一键重复插入，会同时申请间隙锁（gap lock）和插入意向锁（insert intention lock），而这两类锁互斥。

事务A执行 INSERT INTO t (num1) VALUES (5) ON DUPLICATE KEY UPDATE …，发现num1=5已存在，于是加next-key lock（含gap+record）；
事务B同样执行相同语句，也在同一间隙上申请插入意向锁；
因间隙锁阻塞插入意向锁，且双方都未提交，最终形成死锁。

这种死锁不涉及显式UPDATE，却在批量导入、幂等写入等场景高频出现。

零一万物开放平台

零一万物大模型开放平台

查看详情

归档/迁移类操作引发的隐性死锁

业务中常见的“查后删”“查后插”逻辑，在高并发下极易出问题。

事务A：BEGIN; INSERT INTO history SELECT * FROM main WHERE id=1; DELETE FROM main WHERE id=1;
事务B：BEGIN; INSERT INTO history SELECT * FROM main WHERE id=1;
A在DELETE前已对main.id=1加了S锁（读），又试图升级为X锁；B也申请S锁，但A的升级请求和B的S锁请求在锁队列中形成依赖闭环。

本质是“共享锁升级冲突”，在InnoDB中表现为S→X升级被阻塞，而其他事务又在等该S锁——死锁判定成立。

如何快速定位死锁现场

别靠猜，用系统自带工具看真实链路：

执行 SHOW ENGINE INNODB STATUS\G，重点关注“LATEST DETECTED DEADLOCK”段，它会明确写出哪两个事务、各自持有什么锁、等待什么锁；
开启全局记录：SET GLOBAL innodb_print_all_deadlocks = ON，所有死锁都会写入错误日志，便于事后批量分析；
查实时状态：SELECT * FROM information_schema.INNODB_TRX 看活跃事务，INNODB_LOCK_WAITS 看谁堵了谁。

基本上就这些。关键不在“怎么杀掉死锁”，而在“怎么让事务按统一顺序拿锁、尽量缩短事务生命周期、避免在RR下做不必要的范围扫描”。

以上就是SQL死锁产生场景分析_SQL实际案例讲解说明的详细内容，更多请关注php中文网其它相关文章！