MySQL 外键删除为什么失败：RESTRICT、CASCADE 与锁等待的排查边界

删除 MySQL 主表记录时，如果子表还保留着引用，InnoDB 通常会直接拒绝这次操作；如果引用已经不存在却一直不返回，问题就更可能落在事务锁上。以订单和订单明细为例，先确认外键动作，再看子表数据和阻塞事务，通常比直接改成 SET FOREIGN_KEY_CHECKS=0 更安全。

先看外键动作，再判断删除结果

外键失败不是一种固定故障。RESTRICT、NO ACTION、CASCADE 和 SET NULL 描述的是删除父行时对关联子行的处理方式。生产库里最容易误判的是：开发者记得“有外键”，却没有确认当前约束到底采用了哪一个动作。

SELECT
  CONSTRAINT_NAME,
  TABLE_NAME,
  COLUMN_NAME,
  REFERENCED_TABLE_NAME,
  REFERENCED_COLUMN_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME IN ('shop_order', 'shop_order_item')
  AND REFERENCED_TABLE_NAME IS NOT NULL;

这个查询能确认谁引用了谁，但还要看约束定义里的删除动作：

SELECT
  CONSTRAINT_NAME,
  TABLE_NAME,
  REFERENCED_TABLE_NAME,
  DELETE_RULE,
  UPDATE_RULE
FROM information_schema.REFERENTIAL_CONSTRAINTS
WHERE CONSTRAINT_SCHEMA = DATABASE()
  AND TABLE_NAME = 'shop_order_item';

如果 DELETE_RULE 是 RESTRICT 或 NO ACTION，删除仍有明细的订单就会失败；如果是 CASCADE，子表记录会随父行一起消失。SET NULL 则要求子表外键列允许为空，否则约束设计本身就不完整。

为什么 RESTRICT 会拒绝父表删除

假设 shop_order_item.order_id 指向 shop_order.id。先查子表，不要先尝试关闭约束：

SELECT id, order_id, sku, quantity
FROM shop_order_item
WHERE order_id = 10086;

DELETE FROM shop_order
WHERE id = 10086;

只要第一条查询返回行，第二条删除在限制型外键下就可能报类似 Cannot delete or update a parent row: a foreign key constraint fails 的错误。正确处理取决于业务规则：订单明细需要保留审计记录时，应先走取消或归档状态；确实允许整单清理时，才考虑在建表或变更约束时使用 CASCADE。

CASCADE 不是临时解锁开关

CASCADE 适合“子数据没有独立生命周期”的场景，例如临时导入批次及其行项目。它不适合用来掩盖后台任务误删主记录的问题。上线前至少做一次事务内验证：

START TRANSACTION;
DELETE FROM shop_order WHERE id = 10086;

SELECT COUNT(*) AS remaining_items
FROM shop_order_item
WHERE order_id = 10086;

ROLLBACK;

在测试库看到 remaining_items = 0 只能说明联动规则生效，还要确认触发删除的账号、备份策略和业务审批都能接受这个结果。不要在生产事务里用大范围条件测试级联删除。

报错和卡住要分开排查

约束冲突通常很快返回；锁等待则表现为删除语句长时间处于执行状态。后者常见于另一个事务更新了同一订单或明细，却迟迟没有提交。

SELECT
  r.REQUESTING_ENGINE_TRANSACTION_ID AS waiting_trx,
  r.BLOCKING_ENGINE_TRANSACTION_ID AS blocking_trx,
  w.OBJECT_SCHEMA,
  w.OBJECT_NAME,
  w.INDEX_NAME,
  w.LOCK_TYPE,
  w.LOCK_MODE
FROM performance_schema.data_lock_waits AS r
JOIN performance_schema.data_locks AS w
  ON w.ENGINE_TRANSACTION_ID = r.REQUESTING_ENGINE_TRANSACTION_ID;

不同 MySQL 版本的性能库字段可能略有差异，查询报字段不存在时先检查 performance_schema.data_locks 的列定义。也可以查看：

SHOW ENGINE INNODB STATUS\G

如果发现阻塞事务，先定位连接所属的应用和事务开始时间，再决定让业务提交、回滚，或在确认无害后结束连接。这里别急着杀掉持锁会话：它可能正处于一笔需要完整回滚的业务事务中。

几个容易留下隐患的处理方式

发布前用一组小检查确认边界

1. 记录约束名、父表、子表和 DELETE_RULE。
2. 用同一个主键查询子表引用数量，确认是否存在孤儿数据或意外引用。
3. 若语句卡住，记录等待事务和阻塞事务，不把锁等待误判成外键错误。
4. 在事务中验证级联效果，确认结果后回滚测试事务。
5. 将删除动作放入业务权限、审计和备份流程，而不是只修改数据库开关。

相关问题

为什么 NO ACTION 看起来和 RESTRICT 一样？

在 MySQL InnoDB 的常见使用方式下，两者都会阻止仍有引用的父行删除。不要只看建表语句中的名字，最终以 REFERENTIAL_CONSTRAINTS.DELETE_RULE 和实际测试结果为准。

子表先删了，父表删除仍然失败怎么办？

先确认删除子表的事务已经提交，并检查是否还有其他子表或历史约束引用父表。只删除你看到的一张子表，不代表整个数据库没有引用。

可以用 FOREIGN_KEY_CHECKS=0 修复线上删除吗？

不建议把它当作常规修复方案。它可能让不一致数据进入库，后续查询和恢复更难判断；应先明确约束设计、清理顺序和可回滚方案。

总结

MySQL 外键删除失败时，先用元数据确认删除动作，再查询子表引用；如果语句不是立即报错而是持续等待，就转向 InnoDB 锁和未提交事务。把“约束不允许删除”和“事务暂时拿不到锁”分成两条路径，才能避免用关闭约束或强杀连接的方式扩大故障。