必须用BEFORE DELETE，因需在主表记录删除前获取OLD.id等关键值清理子表；AFTER中行已物理删除且禁止操作原表，易报ERROR 1442。
DELETE 触发器必须用 BEFORE 还是 AFTER？
必须用 BEFORE DELETE。因为清理关联数据的动作要发生在主表记录真正被删掉之前；如果用 AFTER，主表行已消失，你就拿不到 OLD.id 等关键值，也没法可靠定位要删的子表记录。
常见错误现象：ERROR 1442 (HY000): Can't update table 'orders' in stored function/trigger because it is already used by statement which invoked this stored function/trigger —— 这通常是因为在 AFTER 触发器里又去查或删同一张主表，MySQL 显式禁止这种递归操作。
-
BEFORE DELETE可安全读取OLD.*字段，并执行对其他表的DELETE或UPDATE - 触发器体中不能包含事务控制语句（如
COMMIT），MySQL 不允许在触发器内显式启停事务 - 若子表有外键且设了
ON DELETE CASCADE，就根本不需要手动写触发器——优先检查是否已有约束覆盖该逻辑
如何避免触发器误删非关联数据？
核心是精准匹配外键关系。比如主表 users 的 id 被子表 posts 的 user_id 引用，触发器里必须用 OLD.id = posts.user_id，而不是模糊条件（如 LIKE 或未加 WHERE）。
示例（MySQL）：
CREATE TRIGGER tr_user_delete_cleanup BEFORE DELETE ON users FOR EACH ROW BEGIN DELETE FROM posts WHERE user_id = OLD.id; DELETE FROM comments WHERE user_id = OLD.id; END;
- 务必确认子表字段类型与主表一致（例如都是
BIGINT UNSIGNED），否则隐式转换可能导致索引失效、漏删 - 如果子表数据量大（比如百万级
posts），直接DELETE可能锁表太久；考虑分批删或改用异步任务，触发器只负责发通知 - 不要在触发器里调用存储过程来删数据，除非该过程明确不访问当前正在被删的主表
PostgreSQL 和 SQL Server 的写法差异在哪？
语法结构不同，但逻辑一致：都靠 OLD（或 DELETED）获取待删行，再主动清理子表。
PostgreSQL 示例（使用 OLD 和 EXECUTE 动态执行）：
CREATE OR REPLACE FUNCTION cleanup_on_user_delete() RETURNS TRIGGER AS $$ BEGIN DELETE FROM posts WHERE user_id = OLD.id; RETURN OLD; END; $$ LANGUAGE plpgsql; CREATE TRIGGER tr_user_delete BEFORE DELETE ON users FOR EACH ROW EXECUTE FUNCTION cleanup_on_user_delete();
SQL Server 示例（使用 DELETED 临时表）：
CREATE TRIGGER tr_user_delete_cleanup ON users INSTEAD OF DELETE AS BEGIN DELETE p FROM posts p INNER JOIN DELETED d ON p.user_id = d.id; DELETE FROM users WHERE id IN (SELECT id FROM DELETED); END;
- PostgreSQL 不支持
INSTEAD OF在普通表上，只能用BEFORE+ 函数封装 - SQL Server 常用
INSTEAD OF替代BEFORE，但要注意：它会完全替代原DELETE，所以最后得手动删主表（如示例末行） - 所有数据库中，触发器都不能返回结果集；若触发器里写了
SELECT，多数会报错（如 PostgreSQL 报query has no destination）
为什么生产环境要慎用级联删除触发器？
因为它把“单条 DELETE”悄悄扩展成 N 次 I/O 操作，且这些操作不可见、不可控、难以监控。
- 一条
DELETE FROM users WHERE id = 123可能实际引发上千行子表扫描+删除，导致慢查询、锁等待甚至超时 - 日志里只记主表操作，DBA 查慢日志时看不到背后隐藏的子表动作，排查成本陡增
- 如果某次部署忘了同步更新触发器逻辑（比如新增了
notifications表但没加进触发器），就会出现数据残留，而外键约束能强制你面对这个关系 - 测试时容易漏掉多层嵌套场景（如用户 → 订单 → 订单项 → 日志），触发器很难自动推导完整依赖链
真正需要触发器的，往往是那些无法加外键的场景：跨库、跨 schema、JSON 关联字段、或历史遗留无约束表。其余情况，先看能不能用 ON DELETE CASCADE 或应用层显式清理。
