ON DELETE CASCADE 和 ON UPDATE CASCADE 是死锁高发区，真正可控方案是将级联逻辑迁移至业务层：显式按固定顺序操作（先子后父）、为外键列建独立索引、所有路径统一事务与锁序，并保留外键约束仅禁用级联动作。
直接说结论：ON DELETE CASCADE 和 ON UPDATE CASCADE 是死锁高发区，不是“用了省事”，而是“用了埋雷”。真正可控的方案是把级联逻辑从 InnoDB 内部移出来，交由业务层显式控制。
为什么 ON DELETE CASCADE 会触发 ABBA 死锁
外键级联本身不加锁，但它触发的隐式子表操作由 InnoDB 内部调度——你完全无法干预它的锁顺序、时机或范围。当事务 A 显式先删子表再删父表，而事务 B 走级联先删父表（触发子表删除），两个事务就天然构成 A→B→A 的锁等待环。
- 现象：
Deadlock found when trying to get lock，SHOW ENGINE INNODB STATUS显示两个事务分别持有parent_table和child_table的 X 锁，并互相等待 - 关键线索：日志里出现
lock_mode X locks index `fk_idx`，但你的 SQL 根本没写那条子表 DELETE - 根本原因：InnoDB 对子表的扫描路径不可控，锁序与应用层 SQL 不一致，ABBA 死锁几乎必然发生
子表外键列没索引 = 实际上的表锁
哪怕你已禁用级联，只要 child_table.parent_id 没独立索引，每次涉及外键检查（INSERT/UPDATE/DELETE 父表）都会全表扫描子表，进而对整张子表加意向排他锁（IX），后续任何 DML 都会被阻塞——这不是死锁，是卡死，更难定位。
- 必须建索引：
ALTER TABLE child_table ADD INDEX idx_parent_id (parent_id) - 联合索引无效：如已有
(status, parent_id)，它对WHERE parent_id = ?完全不生效 - 类型必须严格一致：若父表主键是
BIGINT UNSIGNED，子表外键列也得是，否则隐式转换导致索引失效
业务层替代级联的实操要点
迁移不是删掉外键就完事，而是用可审计、可加锁、可顺序控制的方式重写逻辑。核心是「查 ID → 批量删/改 → 删/改父表」，全部在单事务内完成。
- 查子记录必须带
FOR UPDATE：SELECT id FROM child_table WHERE parent_id = ? FOR UPDATE，否则可能读到旧快照，漏操作 - 避免
DELETE JOIN或子查询：它们会引入不可控锁范围和执行计划抖动 - 批量操作 IN 列表长度建议 ≤ 1000：超长易让优化器放弃索引，退化为全表扫描
- 所有业务路径必须统一顺序：推荐「先子后父」，因为子表数据量通常更大，早释放更安全
- 外键约束仍保留：仅禁用级联动作（
ON DELETE NO ACTION），靠应用层+索引+事务兜底数据一致性
容易被忽略的隔离级别陷阱
即使逻辑和索引都正确，REPEATABLE READ 下的 Next-Key Lock 仍可能因间隙锁扩大阻塞面。尤其在高并发更新场景，WHERE parent_id = ? 可能锁住整个间隙，导致插入新子记录失败或等待。
- 临时降级到
READ COMMITTED是有效手段：SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED - 注意副作用：RC 下不再有间隙锁，需确认业务能否接受幻读风险（多数级联场景无影响）
- ORM 框架务必清理残留配置：如 Django 的
on_delete=models.CASCADE、Rails 的dependent: :destroy，它们会绕过你写的业务逻辑
最麻烦的点不在代码怎么写，而在“所有路径是否真的都走同一套逻辑”——漏掉一个定时任务、一个后台脚本、一个老接口，就可能让外键约束瞬间变成死锁导火索。上线前必须全链路扫描 ORM 配置和原始 SQL，确保没有隐式级联残留。
