DELETE 死锁的本质与定位策略

DELETE 操作容易触发死锁，其根本原因在于多个事务以不同的顺序争抢同一索引间隙（例如范围 (1,9)）。由于间隙锁具有不可降级且不共享的特性，并且与插入意向锁存在互斥关系，从而形成了典型的循环等待条件。解决这一问题的核心步骤，首先需要通过 SHOW ENGINE INNODB STATUS 命令来定位具体的死锁链条，随后结合 INNODB_TRX 和 performance_schema.data_locks 表，精确确认锁的持有者与等待者身份。

需要明确的是，DELETE 触发死锁并非语句本身的语法错误，而是多个事务以不同顺序访问相同资源（包括索引、行记录或间隙）所导致的循环等待现象。解决的关键在于厘清“谁在等待谁”、“等待的原因是什么”以及“如何打破循环”，而非盲目地重试语句或强行终止进程。

MySQL 中查当前死锁或锁等待状态

首先需确认当前状况是真正的死锁，还是单纯的锁等待超时（ERROR 1205 或 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）。MySQL 系统不会静默卡死，它要么直接抛出错误，要么等待超时后返回结果。

• SHOW ENGINE INNODB STATUS 是最直接的排查入口。在输出信息中查找 ------------------------ 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 较大的事务，这些往往是阻塞源头。
• performance_schema.data_lock_waits 表能关联出哪个事务正在等待哪个事务的锁，但需配合 performance_schema.data_locks 使用。注意 MySQL 8.0+ 版本已移除旧版相关表，转而采用 performance_schema.data_locks 进行更精细的锁监控。

Oracle 中如何快速终止阻塞 DELETE 的会话

与 MySQL 自动选择事务进行回滚不同，Oracle 需要人工干预来处理死锁。重点不在于“杀死哪个会话”，而在于“杀死正确的会话”——即只终止那些真正持有锁且未提交的事务会话，从而避免误杀正在执行关键业务逻辑的连接，确保系统稳定性。

2/4

• 先查被锁对象和会话：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），而不同事务若扫描路径不一致（比如一个走主键，一个走二级索引），就极易交叉加锁。

避免 DELETE 死锁的实操建议

预防比处理更重要。线上系统一旦出现死锁，说明事务设计或索引策略已有隐患。

• 确保所有涉及相同表的写操作（INSERT/UPDATE/DELETE），按完全相同的索引顺序访问数据。比如都强制走主键范围扫描，或都走某个覆盖索引，避免一个走主键、一个走二级索引
• DELETE 前加 SELECT ... FOR UPDATE 显式锁定，但必须保证 SELECT 和 DELETE 使用同一索引条件，否则 SELECT 加的锁和 DELETE 实际加的锁可能不一致
• 大范围 DELETE 拆成小批量（如每次 1000 行），用 WHERE id BETWEEN AND + 主键驱动，减少单次锁持有时间和范围
• 检查事务是否过长：DELETE 前有没有没必要的 SELECT、远程调用、循环逻辑？把事务粒度收窄，能极大降低死锁概率

深入排查死锁根源

真正棘手的不是怎么杀会话，而是当两个 DELETE 语句都看似合理、索引也正确、事务也不长，却仍周期性死锁——这时得深挖执行计划是否因统计信息陈旧导致走错索引，或者是否存在隐式类型转换让索引失效。这类问题不会在日志里直接告诉你，得靠 EXPLAIN 对比、锁视图交叉验证才能揪出来。