mysql触发器中不能直接使用delete join语法，仅支持标准单表delete或子查询方式；postgresql虽支持using等语法，但在触发器内需显式声明变量并注意for each row与statement的执行粒度差异。
触发器里不能直接用 DELETE ... JOIN 语法
MySQL 5.7+ 和 PostgreSQL 都不支持在 DELETE 语句中直接写 JOIN，比如 DELETE t1 FROM table1 t1 JOIN table2 t2 ON t1.id = t2.ref_id 这种写法在触发器里会报错或行为不可靠。真正能用的只有标准单表 DELETE 或子查询方式。
常见错误现象是：触发器编译通过，但执行时提示 Can't specify target table for update in FROM clause（MySQL）或 relation "xxx" does not exist（PostgreSQL 的 WITH 子句作用域问题）。
- MySQL 中必须用
(SELECT id FROM deleted_table)这类子查询绕过限制，不能在FROM里引用正被删除的表 - PostgreSQL 可用
WITH RECURSIVE或USING子句，但触发器函数内需显式声明变量承接主键值 - 所有数据库都不允许在
BEFORE DELETE触发器里修改当前行所在表，否则会循环触发或报错
BEFORE DELETE 触发器比 AFTER 更安全
级联删除逻辑放在 BEFORE DELETE 触发器里，才能确保关联记录先删、主记录后删，避免外键约束冲突或残留脏数据。如果用 AFTER，主记录已删，再查外键关联可能返回空结果，导致级联失败。
典型使用场景：用户表 users 被删时，要同步清理 orders、profiles、user_logs 三张表。其中 orders 还有外键指向 products，但不应由该触发器处理——级联应限于直接依赖，避免跨层蔓延。
-
BEFORE触发器里可直接读取OLD.id，无需额外查询 - 若某张关联表有
ON DELETE CASCADE，就别再在触发器里重复删它，否则可能报duplicate key或静默跳过 - PostgreSQL 中
BEFORE函数返回NULL会取消本次删除，务必返回OLD
性能瓶颈常出现在子查询嵌套和事务锁范围
一个 BEFORE DELETE 触发器若包含 3 层子查询删 4 张表，实际执行时可能锁住整个 users 表，尤其在高并发下容易阻塞其他 SELECT。这不是语法错误，而是设计疏忽。
参数差异明显：MySQL 的触发器对单条语句生效，而 PostgreSQL 的触发器默认是每行触发（FOR EACH ROW），批量删 1000 行用户就会执行 1000 次级联逻辑，必须改用 FOR EACH STATEMENT 并配合 array_agg(OLD.id) 批量处理。
- MySQL 不支持语句级触发器，只能靠应用层控制批量删除粒度（如每次最多删 100 行）
- 所有数据库中，触发器内的
DELETE都继承主事务的隔离级别，READ COMMITTED下仍可能遇到幻读导致漏删 - 避免在触发器里调用存储过程做复杂判断，延迟和锁等待会指数级放大
外键约束与触发器共存时必须明确责任边界
如果 orders.user_id 已设 FOREIGN KEY ... ON DELETE CASCADE，再写触发器去删 orders 就是冗余且危险的。两者叠加可能导致部分记录被删两次，或触发器因外键已删而查不到关联数据，逻辑中断。
真实项目中最容易被忽略的是“软删除”字段干扰。比如 users.deleted_at IS NOT NULL 视为逻辑删除，但触发器没判断这个字段，就会误删已被软删用户的订单。
- 优先用外键
ON DELETE CASCADE处理强一致性关联（如订单-用户），触发器只补足外键无法覆盖的场景（如日志归档、统计表更新） - 触发器开头必须加
IF OLD.deleted_at IS NULL THEN ... END IF;类判断，否则和软删除机制冲突 - 测试时一定要用
START TRANSACTION; DELETE ...; ROLLBACK;验证，不能只看单次执行结果
