外键约束导致delete失败的典型报错是“error 1451: cannot delete or update a parent row”，因子表存在引用而被数据库强制拦截；解决方式包括on delete cascade（自动级联删除）、手动分步删除（事务内先子后父）、on delete set null（字段需允许null）或软删除（加is_deleted标志），需据业务意义选择。
外键约束导致 DELETE 失败的典型报错
直接 DELETE FROM parent_table 会触发外键约束，报错类似：ERROR 1451 (HY000): Cannot delete or update a parent row: a foreign key constraint fails。这不是语法错误，而是 MySQL/PostgreSQL 等主流数据库的强制保护机制——子表里还有关联记录时，父表记录不允许被删。
ON DELETE CASCADE：让数据库自动清理子表
最省事的方案是在建表时或修改外键时加上 ON DELETE CASCADE。它让数据库在删父表行时，自动级联删除所有匹配的子表行。
示例（MySQL）：
ALTER TABLE child_table ADD CONSTRAINT fk_parent_id FOREIGN KEY (parent_id) REFERENCES parent_table(id) ON DELETE CASCADE;
注意点：
-
ON DELETE CASCADE是 DDL 操作，需有ALTER权限，且不能对已存在的外键直接修改（需先DROP再ADD） - 级联删除不可回滚（即使在事务中），一旦触发，子表数据永久消失
- 若子表数据量大，
CASCADE可能引发锁等待或超时，尤其在高并发写场景下
手动先删子表再删父表：更可控但需显式控制顺序
适合已有表结构无法改外键、或需要审计/备份子表数据的场景。核心是保证执行顺序：先删子表，再删父表，且必须在同一个事务里。
示例（带事务）：
BEGIN; DELETE FROM child_table WHERE parent_id IN (SELECT id FROM parent_table WHERE condition); DELETE FROM parent_table WHERE condition; COMMIT;
关键细节：
- 子表
DELETE的WHERE条件必须和父表一致，否则可能漏删或多删 - 避免用
IN (SELECT ...)处理上万行数据（MySQL 可能慢），改用JOIN或分批处理 - PostgreSQL 支持
DELETE ... USING语法，效率更高；MySQL 则常用多表DELETE：DELETE c FROM child_table c JOIN parent_table p ON c.parent_id = p.id WHERE p.condition
SET NULL 或 RESTRICT：按业务逻辑选行为
不是所有场景都该删子表。比如订单（父）和订单项（子），删订单时可能希望保留订单项用于归档，只需把 order_id 设为 NULL（前提是字段允许 NULL）。
对应外键定义：
FOREIGN KEY (order_id) REFERENCES orders(id) ON DELETE SET NULL
或者明确禁止删除（默认行为）：
FOREIGN KEY (order_id) REFERENCES orders(id) ON DELETE RESTRICT
注意：
-
SET NULL要求外键列声明为NULL，否则建表失败 -
RESTRICT和不写ON DELETE效果一样，但显式写出更易读 - 业务上“软删除”（如加
is_deleted字段）常比物理删除更安全，此时外键约束可保持原样
真正麻烦的从来不是语法怎么写，而是删之前没想清楚：这些子记录到底有没有独立业务意义？下游系统是否还在引用？备份和日志有没有覆盖这个操作路径？
