SQL触发器可以实现跨表的自动级联删除吗

MySQL 必须用 BEFORE DELETE 触发器清理子表，AFTER 会因 ERROR 1442 失败；PostgreSQL 和 SQL Server 更推荐外键 ON DELETE CASCADE 或 INSTEAD OF 触发器，避免手动逻辑踩坑、难维护。

可以，但必须用 BEFORE DELETE，且仅限于 MySQL 中需手动补逻辑的场景；PostgreSQL 和 SQL Server 更推荐用外键 ON DELETE CASCADE 或 INSTEAD OF 触发器——不是不能做，而是容易踩坑、难维护。

MySQL 必须用 BEFORE DELETE，AFTER 会报 ERROR 1442

MySQL 在 AFTER DELETE 触发器里禁止对原表做任何读写操作（包括 SELECT 或 JOIN），否则直接抛出 ERROR 1442 (HY000)。因为行已物理删除，OLD.id 虽然还能访问，但无法安全定位子表关联数据（尤其当子表字段类型不一致时可能漏删）。

• BEFORE DELETE 才能可靠拿到 OLD.id，并执行 DELETE FROM child WHERE parent_id = OLD.id
• 必须加 DELIMITER $$ 包裹触发器体，否则分号会让 MySQL 提前结束语句
• 触发器内不能写 COMMIT 或 START TRANSACTION，MySQL 不允许显式事务控制
• 如果子表已有外键 ON DELETE CASCADE，就根本不需要这个触发器——先查约束是否存在

PostgreSQL 优先用外键 CASCADE，触发器只用于复杂逻辑

PostgreSQL 原生支持 ON DELETE CASCADE，性能好、原子性强、可预测。触发器（如 BEFORE DELETE + 函数）只应在需要条件判断、日志记录或跨 schema 清理时才介入。

• 建外键必须显式写 ON DELETE CASCADE，光有 REFERENCES 不生效
• 若子表数据已存在，添加约束前要确保所有 parent_id 都指向真实父记录，否则 ADD CONSTRAINT 会失败并提示 violates foreign key constraint
• 级联深度无硬限制，但嵌套超 3 层（如 A→B→C→D）时，DELETE FROM A 可能锁表数秒，需评估业务容忍度

SQL Server 的 INSTEAD OF 触发器必须手动删父表

SQL Server 的 INSTEAD OF DELETE 会完全接管删除动作，但有个致命陷阱：它不会自动删父表本身——你得在触发器里显式写 DELETE FROM parent_table WHERE id IN (SELECT id FROM deleted)，否则看起来“级联”了，其实父表还在。

• deleted 是只读临时表，仅在触发器内可见，存着本次将被删的行
• 若子表也有 INSTEAD OF 触发器，需确认是否开启嵌套触发器：sp_configure 'nested triggers', 1
• 多个子表清理建议用 JOIN 或分步 DELETE，避免单条语句锁表太久

真正麻烦的不是写法，而是递归调用和隐式类型转换——比如主表 id 是 BIGINT UNSIGNED，子表 parent_id 是 INT，MySQL 会隐式转成有符号整型，导致索引失效、漏删；又或者父子表双向外键，触发器一触发就死循环。这些细节不跑通测试根本看不出来。