DELETE易触发死锁的本质是多个事务以不同顺序争抢同一索引间隙（如(1,9)），因间隙锁不可降级、不共享，且与插入意向锁互斥，导致循环等待；关键需通过SHOW ENGINE INNODB STATUS定位死锁链，再查INNODB_TRX和performance_schema.data_locks确认锁持有者与等待者。
DELETE 操作触发死锁，本质不是语句本身有问题，而是多个事务以不同顺序访问相同资源（如索引、行、间隙），形成循环等待。解决的关键是「定位谁在等谁」「为什么等」「怎么打破循环」，而不是盲目重试或杀进程。
查当前死锁或锁等待状态（MySQL）
先确认是不是真死锁，还是单纯锁等待超时（ERROR 1205 或 ERROR 1213）。MySQL 不会静默卡住，它要么报错，要么等超时。
-
SHOW ENGINE INNODB STATUS\G是最直接的入口，输出里找------------------------ LATEST DETECTED DEADLOCK ------------------------段落，里面会明确写出两个事务的 SQL、持有的锁、等待的锁、线程 ID - 如果没看到死锁记录，但 DELETE 卡住或报
Lock wait timeout exceeded，说明是长事务阻塞：查SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING'，重点关注trx_started时间早、trx_rows_modified大的事务 -
SELECT * FROM information_schema.INNODB_LOCK_WAITS能关联出哪个事务在等哪个事务的锁，但需配合INNODB_TRX和INNODB_LOCKS（MySQL 8.0+ 已移除后者，改用performance_schema.data_locks）
Oracle 中如何快速终止阻塞 DELETE 的会话
Oracle 不像 MySQL 自动选事务回滚，得人工干预。重点不是“杀谁”，而是“杀对人”——只杀真正持有锁且不提交的会话，避免误杀正在执行关键逻辑的连接。
- 先查被锁对象和会话：
SELECT s.username, s.sid, s.serial#, s.status, s.machine, s.program, l.object_id FROM v$session s, v$locked_object l WHERE s.sid = l.session_id - 再查这些会话正在跑什么 SQL：
SELECT sql_text FROM v$sql WHERE hash_value IN (SELECT sql_hash_value FROM v$session WHERE sid IN (SELECT session_id FROM v$locked_object)) - 确认无误后执行：
ALTER SYSTEM KILL SESSION 'sid,serial#'—— 注意单引号不能少，且sid和serial#必须来自上一步查询结果，不能凭记忆手输 - 如果
KILL SESSION后会话状态变成KILLED但锁仍未释放，说明进程在 OS 层还没退出，需登录服务器查ps -ef | grep ora_找对应spid，再用kill -9
为什么 DELETE 容易引发死锁（尤其在 MySQL RR 隔离级）
根本原因在于 InnoDB 的加锁机制：DELETE 不只锁匹配的行，还会锁索引范围（Next-Key Lock），而不同事务若扫描路径不一致（比如一个走主键，一个走二级索引），就极易交叉加锁。
- 例如表有主键
id和二级索引date，事务 A 执行DELETE FROM t WHERE date （走idx_date），事务 B 执行DELETE FROM t WHERE id = 123（走主键），两者可能分别持有对方需要的间隙锁或记录锁 - 唯一索引上的等值 DELETE（如
WHERE a = 2）也可能死锁：事务 A 先锁了索引 a=2 的记录，事务 B 在同一时刻尝试插入a=2（违反唯一约束），就会申请 S 锁，而 A 持有 X 锁未释放，B 等 A；同时 B 若已持有其他锁，A 又反过来等 B，死锁闭环形成 - 批量 DELETE（如
date ）比单行更危险，因为它会扫描并锁住更大范围的索引间隙，提高与其他事务冲突概率
避免 DELETE 死锁的实操建议
预防比处理更重要。线上系统一旦出现死锁，说明事务设计或索引策略已有隐患。
- 确保所有涉及相同表的写操作（INSERT/UPDATE/DELETE），按**完全相同的索引顺序**访问数据。比如都强制走主键范围扫描，或都走某个覆盖索引，避免一个走主键、一个走二级索引
- DELETE 前加
SELECT ... FOR UPDATE显式锁定，但必须保证 SELECT 和 DELETE 使用**同一索引条件**，否则 SELECT 加的锁和 DELETE 实际加的锁可能不一致 - 大范围 DELETE 拆成小批量（如每次 1000 行），用
WHERE id BETWEEN ? AND ?+ 主键驱动，减少单次锁持有时间和范围 - 检查事务是否过长：DELETE 前有没有没必要的 SELECT、远程调用、循环逻辑？把事务粒度收窄，能极大降低死锁概率
真正棘手的不是怎么杀会话，而是当两个 DELETE 语句都看似合理、索引也正确、事务也不长，却仍周期性死锁——这时得深挖执行计划是否因统计信息陈旧导致走错索引，或者是否存在隐式类型转换让索引失效。这类问题不会在日志里直接告诉你，得靠 EXPLAIN 对比、锁视图交叉验证才能揪出来。
