级联删除由外键ON DELETE CASCADE约束强制执行，非SQL语句可绕过；禁用需临时关外键检查（MySQL）或手动清理子表再删父表，永久停用须查名、删旧约束、重建为RESTRICT。
DELETE触发级联删除但你不想要？先确认是不是真开了CASCADE
看到删一行带出几十行，第一反应别急着拦，先查外键定义。很多“意外级联”其实是建表时误加了 ON DELETE CASCADE，或者开发环境配置被同步到了生产库。执行以下语句查子表外键行为：
- MySQL：
SELECT CONSTRAINT_NAME, UPDATE_RULE, DELETE_RULE FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE kcu JOIN INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS rc ON kcu.CONSTRAINT_NAME = rc.CONSTRAINT_NAME WHERE kcu.TABLE_NAME = 'child_table'; - PostgreSQL：
SELECT conname, confupdtype, confdeltype FROM pg_constraint WHERE confrelid = 'child_table'::regclass;（confdeltype = 'c'表示 CASCADE）
如果结果里真有 c 或 CASCADE，那不是“触发了不必要的级联”，而是数据库按你写的约束在严格执行——问题出在约束本身，不在 DELETE 语句。
已有CASCADE外键，但临时想禁用级联行为
不能靠改 SQL 语句绕过，DELETE FROM parent WHERE id = 123 一旦外键设了 CASCADE，就一定会级联。真正可行的只有两种路径：
- MySQL：临时关外键检查
SET FOREIGN_KEY_CHECKS = 0;，删完再开= 1。但注意：这不会“禁用级联”，而是彻底跳过外键逻辑——主表删了，子表数据全留下，变成孤儿记录 - PostgreSQL：没有等效开关；必须用
BEGIN; SET CONSTRAINTS ALL DEFERRED;配合事务，但这只影响 DEFERRABLE 约束，且不改变 CASCADE 语义 - 最稳妥的做法：删之前手动清理子表，比如先
DELETE FROM child_table WHERE parent_id = 123;，再删主表。这样完全可控，也留有回滚余地
想永久停用级联，但表已上线，怎么安全改外键
直接 ALTER TABLE ... ADD FOREIGN KEY ... ON DELETE CASCADE 是错的——那是加新约束。你要的是替换旧约束，步骤固定且不可省略：
- 先查外键名：
SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'orders' AND COLUMN_NAME = 'user_id'; - 再删它：
ALTER TABLE orders DROP FOREIGN KEY fk_orders_user_id;（把上一步查到的名字填进去） - 最后重建，去掉
ON DELETE CASCADE，改用ON DELETE RESTRICT或干脆不写（默认就是 RESTRICT）
PostgreSQL 略宽松，支持 ALTER TABLE child_table DROP CONSTRAINT fk_name; ALTER TABLE child_table ADD FOREIGN KEY (col) REFERENCES parent(col) ON DELETE RESTRICT;。但无论哪种，操作前必须锁表或选低峰期，否则删约束瞬间可能引发应用报错。
为什么INSTEAD OF或BEFORE DELETE触发器拦不住级联删除
因为级联删除是约束驱动的底层动作，不是用户发起的 DML 语句。SQL Server 明确禁止对含 ON DELETE CASCADE 的表创建 INSTEAD OF DELETE 触发器，建的时候就报 Msg 3724。MySQL 和 PostgreSQL 的 BEFORE DELETE 触发器也只作用于显式执行的 DELETE 语句，对数据库自动触发的级联动作完全无感知。
换句话说：你想拦的不是“人删主表”，而是“数据库自己删子表”。后者不走触发器路径，只走外键约束引擎。唯一干预点，就是约束定义本身——要么改行为，要么删约束。
最容易被忽略的一点：级联删除不经过任何应用层钩子、不触发触发器、不写审计日志、也不通知消息队列。它安静、高效、不可见，也正因如此，一旦配错，连补救痕迹都难追溯。
