on delete cascade本身不直接触发死锁，但会放大死锁概率：因其隐式子表删除与父表操作形成跨表锁链，易因锁序不一致导致abba死锁；真实风险来自应用层手动删子表与级联路径冲突、外键列无索引引发全表扫描锁、大批量或深层级联延长锁持有时间。
ON DELETE CASCADE 会触发死锁吗
不会——只要外键定义正确、事务内只删主表单行或小批量，ON DELETE CASCADE 本身不引入死锁风险。它由 InnoDB 在单个事务内原子执行，子表删除顺序严格按外键依赖拓扑排序，不会出现 A 等 B、B 等 A 的循环等待。
但真实死锁往往来自外部干扰：
- 应用层在同一个事务里手动
DELETE子表后再删主表——和级联路径冲突，InnoDB 检测到锁等待闭环就报ERROR 1213 (40001): Deadlock found when trying to get lock - 并发删不同主键但关联同一子表记录（比如两个客户共用一个地址），子表索引行锁被交叉持有
- 级联深度大（>5 层）+ 大批量操作（如
DELETE FROM customers WHERE region = 'CN'），锁持有时间长，撞上其他业务更新
DELETE JOIN 多表删除如何避免锁表过久
DELETE t1, t2 FROM orders t1 INNER JOIN order_items t2 ON t1.id = t2.order_id 这类语句看似高效，实际极易锁表。MySQL 会对 JOIN 结果集里的每行 t1 和 t2 同时加 X 锁，且锁持续到事务结束。
安全做法是分步、限流、走索引：
- 必须确保
t2.order_id有索引——没索引就会对order_items全表加锁，哪怕只删 1 条订单 - 批量删时用主键范围切片：
WHERE t1.id BETWEEN 1000 AND 1999，每次最多删 1000 行，中间COMMIT - 别在
DELETE ... JOIN里混用ORDER BY或LIMIT——MySQL 5.7+ 虽支持，但LIMIT不保证删的是“最早”那批，可能跳过某些关联行 - 线上执行前先
EXPLAIN FORMAT=TREE看是否走了索引；若显示type: ALL，立刻停手
为什么加了 ON DELETE CASCADE 还报 ERROR 1451
不是级联失效，是外键约束根本没生效。常见原因：
- 建表时写了
FOREIGN KEY但漏了ON DELETE CASCADE，只留了个空约束，删主表仍被拦 - 字段类型不一致：主表
id INT UNSIGNED，子表ref_id INT—— unsigned 和 signed 视为不同类型，外键创建失败（SHOW CREATE TABLE里压根看不到该外键） - 存储引擎不是 InnoDB：
MyISAM表加了ON DELETE CASCADE也当注释处理，删主表照样报错 - 子表有多个外键指向同一主表，但只给其中一个加了
CASCADE，另一个没加，也会拦删（MySQL 要求所有外键都允许级联才放行）
真正要盯住的不是语法，是锁粒度和事务长度
无论用 ON DELETE CASCADE 还是 DELETE JOIN，只要一次删超过 5000 行，InnoDB 就大概率升级为页锁甚至表锁，其他查询开始排队。更麻烦的是：级联删除无法中断，删到一半出错（比如磁盘满、连接断），整个事务回滚，但已持有的锁可能卡住别的业务几秒。
生产环境最稳的姿势其实是“假删 + 异步清”：
- 主表加
is_deleted TINYINT DEFAULT 0，删时只UPDATE SET is_deleted = 1 - 用低峰期跑后台任务，按主键分片扫
WHERE is_deleted = 1，逐批删子表再删主表物理行 - 所有删除操作加
SELECT ... FOR UPDATE SKIP LOCKED避免重复处理
这法子慢一点，但锁时间短、可中断、可监控进度——比赌一把 CASCADE 不卡库靠谱得多。
