根本原因是RR隔离级别下DELETE对扫描范围加Next-Key Lock，尤其索引缺失或ORDER BY字段非单调时，多个事务反复争抢同一间隙的Gap锁与插入意向锁，形成循环等待。
为什么批量DELETE容易触发死锁
根本不是“删得多”，而是RR隔离级别下DELETE对扫描范围加next-key lock，尤其当WHERE条件没走索引、或用ORDER BY但字段不单调时，InnoDB可能反复扫描同一段间隙（比如(100, 200)），导致多个事务在相同gap上争抢insert intention lock和gap lock，形成循环等待。
典型现象：两个事务同时执行DELETE FROM t WHERE c = 5 LIMIT 100（c是普通索引），又恰有第三个事务想INSERT INTO t VALUES (150, 5, ...)，三者卡在同一个间隙上，SHOW ENGINE INNODB STATUS里能看到lock_mode X locks gap before rec insert intention waiting。
- 索引缺失或失效 → 全表扫 → 锁住大量无关行 → 死锁概率飙升
-
ORDER BY字段非单调（如create_time有重复值）→ 每轮锚点不准 → 下次仍扫到已删/未删区域 → 重叠加锁 - 事务未及时提交 → 所有分批
DELETE堆在一个长事务里 → undo log膨胀 + 锁长期持有
如何让分批DELETE不互相卡住
关键不是“分多少条”，而是让每轮操作的扫描范围严格不重叠、锁立即释放、且只锁真正要删的行。
- 必须用单调递增字段（如
id）做锚点：DELETE FROM t WHERE status = 0 AND id > 12345 ORDER BY id LIMIT 1000，删完立刻记录最后id值（比如13344），下一轮用id > 13344 - WHERE条件必须命中索引：建联合索引
INDEX idx_status_id (status, id)，避免优化器退化为全表扫描 - 每轮执行后立刻
COMMIT：确认SELECT @@autocommit返回1；若用连接池（如Spring），检查@Transactional是否意外包裹了整个循环 - 会话级改隔离级别：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED，让InnoDB只加record lock，不加gap lock，大幅降低间隙冲突
哪些场景该彻底放弃DELETE
当要删的数据占比超过80%，或者单表超千万行、删除耗时预估超5分钟，DELETE就不再是“删数据”，而是“制造风险”。此时物理替换更安全。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 保留少量数据（如只留最近30天）：用
CREATE TABLE t_new LIKE t建空表 →INSERT INTO t_new SELECT * FROM t WHERE create_time >= '2026-09-15'→RENAME TABLE t TO t_old, t_new TO t→DROP TABLE t_old - 表有分区：直接
ALTER TABLE t DROP PARTITION p202501，毫秒级完成，无锁无日志压力 - 业务允许短时只读：停写 →
TRUNCATE TABLE t→ 重灌保留数据，比大DELETE快一个数量级
死锁发生后怎么快速止血
别急着杀会话或重启MySQL。先定位、再收敛，否则可能刚解决A问题，B又爆出来。
- 立刻查死锁现场：
SHOW ENGINE INNODB STATUS\G，重点看LATEST DETECTED DEADLOCK块里的WAITING FOR THIS LOCK TO BE GRANTED和HOLDS THE LOCK(S)两段，确认哪两条SQL在争哪类锁 - 查当前阻塞链：
SELECT * FROM performance_schema.data_lock_waits（MySQL 8.0+）或用INNODB_TRX+INNODB_LOCK_WAITS关联查出blocking_trx_id - 临时降级：对清理任务专用连接，执行
SET SESSION innodb_lock_wait_timeout = 10，让死锁回滚更快，避免长时间挂起 - 事后补索引：如果发现
EXPLAIN FORMAT=JSON里type是ALL或rows远大于实际匹配数，立刻补索引，这是80%批量死锁的根因
最常被忽略的一点：死锁日志里出现lock_mode X locks gap before rec，说明问题不在DELETE本身，而在它和并发INSERT/UPDATE的间隙竞争——这时候光调DELETE逻辑没用，得统一所有涉及该索引字段的DML顺序和隔离级别。
