on delete cascade会放大死锁概率，因其隐式子表删除与父表操作形成跨表锁链，易因锁序不一致触发abba死锁；迁移至业务层需显式按固定顺序删子表再删父表，并为外键列单独建索引防卡死，同时通过校验与稽核防范孤儿数据。
为什么ON DELETE CASCADE会放大死锁概率
外键级联删除本身不直接加锁，但触发时会隐式执行子表的 DELETE 操作，且该操作由 InnoDB 内部调度——你无法控制它加锁的顺序、时机或范围。更关键的是，这个隐式子表删除会和父表的主键更新/删除形成「跨表锁链」，而应用层 SQL 与级联动作的锁序一旦错位（比如事务 A 先删子表再删父表，事务 B 走级联先删父表再删子表），立刻构成 ABBA 死锁模式。
常见现象：Deadlock found when trying to get lock 错误中，SHOW ENGINE INNODB STATUS 显示两个事务分别持有 parent_table 和 child_table 的 X 锁，并互相等待对方释放；日志里还可能出现 lock_mode X locks index `fk_idx`，说明子表外键索引正被争抢，但你根本没写那条 DELETE。
如何把级联删除从数据库层迁移到业务层
迁移不是简单删掉外键，而是用显式、可控、可审计的方式替代隐式行为。核心是：查出要删的子记录 → 批量删子表 → 删父表，全部在同一个事务内完成，并统一加锁顺序。
- 先确认当前外键是否真被依赖：搜代码库里的
ON DELETE CASCADE、ORM 配置（如 Django 的on_delete=models.CASCADE、Rails 的dependent: :destroy），很多只是历史残留 - 用
SELECT id FROM child_table WHERE parent_id = ?查子表 ID 列表，避免DELETE ... JOIN或子查询触发不可控锁 - 用
DELETE FROM child_table WHERE id IN (?,?,?)批量删除，确保id是主键或有索引，避免全表扫描 - 最后执行
DELETE FROM parent_table WHERE id = ?，整个过程包裹在BEGIN; ... COMMIT;中 - 所有业务路径必须严格按「先子后父」或「先父后子」固定顺序，推荐「先子后父」，因为子表数据量通常更大，早释放更安全
不建索引的外键列会直接引发表级锁
即使你已把级联逻辑搬到业务层，只要子表外键列（如 parent_id）没独立索引，InnoDB 在执行 SELECT id FROM child_table WHERE parent_id = ? 时就会全表扫描，进而对整张子表加意向锁（IX），后续任何 DML 都可能被阻塞——这不是死锁，是卡死，但比死锁更难定位。
必须为每个外键列单独建索引，不能依赖联合索引的前缀：
ALTER TABLE child_table ADD INDEX idx_parent_id (parent_id);
验证是否生效：EXPLAIN SELECT id FROM child_table WHERE parent_id = 123; 输出中 key 字段必须显示 idx_parent_id，且 rows 值远小于表总行数。
迁移后仍需补防孤儿数据
去掉外键约束后，应用层漏删子表、事务中途崩溃、或异步任务失败，都会导致孤儿记录。不能靠“反正没人动”赌运气。
至少做三件事：
- 上线前跑一次校验 SQL：
SELECT COUNT(*) FROM child_table c LEFT JOIN parent_table p ON c.parent_id = p.id WHERE p.id IS NULL;结果必须为 0 - 在关键删除路径加应用层校验：删父表前，先
SELECT 1 FROM child_table WHERE parent_id = ? LIMIT 1，非空则报错或走软删 - 部署异步稽核任务，每天扫描并告警孤儿数据，配合自动清理脚本（注意别和业务写冲突）
外键不是开关，是责任转移的分水岭——关掉它容易，但把完整性保障从数据库搬到代码和运维流程里，才是真难点。
