SQL BEFORE、AFTER 触发器使用场景

before触发器需显式赋值new字段以修改数据，after触发器无法修改当前行但可执行日志等事后操作；mysql与postgresql在触发时机、递归限制及语法支持上差异显著。

BEFORE 触发器改写 INSERT/UPDATE 值时，新值必须显式赋值给 NEW

BEFORE 触发器的核心作用是“在语句真正执行前干预数据”，比如自动填充时间戳、标准化字段、校验逻辑。但它不会自动把修改反映到插入或更新的数据上——你得亲手把值塞进 NEW.column_name。

常见错误现象：INSERT INTO users (name) VALUES ('alice') 触发 BEFORE 触发器想补上 created_at，但没写 SET NEW.created_at = NOW()，结果该字段仍是 NULL 或默认值。

• 只读访问 OLD（UPDATE/delete 时可用），只写访问 NEW（INSERT/UPDATE 时可用）
• NEW 是一个可修改的行级上下文，不是变量，不能用 := 或 = 直接赋整个结构体
• 对 NEW.id 赋值后，若表主键是自增，MySQL 会忽略该值并仍走自增逻辑；PostgreSQL 则可能报错或覆盖，取决于定义
• 示例：

  CREATE TRIGGER set_created_at BEFORE INSERT ON users FOR EACH ROW SET NEW.created_at = NOW();

AFTER 触发器无法修改当前语句涉及的行数据

AFTER 触发器只能“响应”已落地的操作，适合做日志记录、异步通知、关联表同步等事后动作。它读得到 OLD 和 NEW，但写它们无效——任何对 NEW.column 的赋值都不会影响刚插入/更新的那行。

使用场景：用户注册成功后，在 user_logs 表里记一笔；订单状态变更为 ‘shipped’ 后，调用 CALL notify_warehouse(...) 存储过程。

• 试图在 AFTER 中写 SET NEW.status = 'processed' 完全无效果，也不报错
• 如果需要“联动更新其他表”，必须用 UPDATE other_table SET ... WHERE id = NEW.other_id 这类显式语句
• 注意事务边界：AFTER 触发器和原语句在同一事务中，回滚会一并撤销
• 性能敏感操作（如发 http 请求）千万别放这里，会拖慢主 DML 执行

MySQL 和 PostgreSQL 对触发器时机的支持差异

语法看着像，行为差得远。MySQL 只支持 BEFORE 和 AFTER，且每个事件最多一个触发器；PostgreSQL 支持更多时机（INSTEAD OF、FOR EACH STATEMENT / ROW），还能同一事件挂多个触发器并控制顺序。

容易踩的坑：

• MySQL 不允许在 BEFORE 触发器里对本表做 INSERT/UPDATE/DELETE（会报 Can't update table 'xxx' in stored function/trigger），PostgreSQL 允许但需小心递归
• PostgreSQL 的 INSTEAD OF 触发器可用于视图，MySQL 没这功能
• MySQL 触发器不支持条件触发（如 WHEN (NEW.amount > 1000)），得靠 IF 块手动判断；PostgreSQL 支持 WHEN 子句过滤
• 参数差异：MySQL 用 NEW/OLD，PostgreSQL 用 NEW/OLD 但需在函数体里声明为 RECORD 类型

触发器里调用存储过程或外部服务的风险点

看似方便，实则埋雷。触发器生命周期短、上下文受限，不适合承担复杂逻辑。

典型问题：

• MySQL 存储过程中调用 SLEEP() 或长耗时查询，会卡住整个事务，影响并发写入
• 试图在触发器里用 select ... INTO OUTFILE 或发起 HTTP 请求（哪怕通过 UDF），多数环境默认禁用或权限不足
• PostgreSQL 中触发器函数若抛出异常（raise EXCEPTION），会直接导致原 DML 失败回滚，而你可能只想跳过某条日志记录
• 调试困难：触发器静默失败时，错误常被吞掉，日志也不一定输出，建议用 INSERT INTO debug_log ... 替代打印

真正该用触发器的地方不多：字段自动填充、简单约束增强、审计字段维护。稍复杂一点的联动，优先考虑应用层处理或定时任务补漏。