SQL的BEFORE UPDATE触发器使用疑问：PostgreSQL与SQL Server实践差异

为什么修改UPDATE写入内容必须用BEFORE UPDATE触发器 #

PostgreSQL中两类行级UPDATE触发器的执行逻辑有本质区别：

• BEFORE UPDATE触发于数据实际写入数据表之前，此时触发器函数返回的NEW记录会作为最终写入的正式数据。你给出的示例中，将NEW.updated赋值为当前时间、用OLD.created覆盖用户提交的修改，这些调整都会直接作用到后续的写入操作，自然可以生效。
• AFTER UPDATE触发于数据已经完成写入、提交到数据表之后，此时PostgreSQL会直接忽略触发器函数的返回值，即使修改NEW变量的内容，也不会同步到已经写完的表记录中，所以你的需求用AFTER UPDATE自然无法生效。如果强行在AFTER阶段实现同类修改，只能额外执行UPDATE语句修改当前行，会二次触发更新触发器，极易引发死循环和性能问题，完全不推荐。

AFTER UPDATE触发器的适用场景 #

AFTER UPDATE的核心特性是触发时可确认当前更新操作已成功完成，不会因约束报错、事务回滚被撤销，适合所有依赖当前更新成功才执行的后置操作，常见场景包括：

• 审计日志留存：记录本次更新的操作人、操作时间、新旧值差异，确保只有更新成功的操作才会留下日志，避免更新回滚后产生无效日志。
• 关联数据同步：比如更新订单表的支付状态后，同步给用户积分表增加对应积分、给消息表插入支付成功通知，所有不需要修改当前更新行、仅需联动其他表的操作都适合用AFTER UPDATE实现。
• 外部系统联动：比如更新商品的上架状态后，调用搜索服务接口更新商品索引，确保只有本地数据更新成功后才同步到外部系统，避免数据不一致。
• 统计指标更新：比如更新订单的完成状态后，同步更新店铺的月度销售额统计值，基于最终写入的有效数据做统计，结果才准确。

内容的提问来源于stack exchange，提问作者Manngo