触发器不能直接复制到应用层，因其依赖数据库事务的原子性、隔离性与一致性；应用层多次SQL执行易导致漏校验、状态不一致或死锁，如订单更新与库存扣减分离后网络中断即产生脏数据。
触发器逻辑不能“无缝”迁移到业务代码——迁移本身必然引入行为差异和风险点，关键在于控制差异数量、暴露隐含依赖、并用测试锚定行为边界。
为什么不能直接复制触发器里的SQL到应用层
触发器运行在数据库事务上下文中，天然具备原子性、隔离性和一致性保障；而应用层调用是外部操作，一次数据库变更可能对应多次应用层SQL执行，稍有疏忽就会漏掉约束、跳过校验、或在异常时留下不一致状态。比如一个Oracle触发器里写的“更新订单后自动扣减库存”，若直接拆成两条独立UPDATE语句放在Java Service里，中间若发生网络中断或JVM崩溃，就只剩“订单已更新但库存没扣”的脏数据。
常见错误现象包括：
-
ORA-00060死锁：原触发器内SELECT FOR UPDATE + UPDATE是单事务内完成，搬出后变成两次独立语句，加锁顺序错乱 - 并发覆盖：两个请求同时读取同一库存值，各自扣减后写回，结果只扣了一次
- 事务范围丢失：触发器中
INSERT INTO audit_log与主表更新同属一个事务，应用层若用异步日志，失败即丢记录
识别哪些触发器必须保留、哪些可安全外移
不是所有触发器都适合搬。优先外移的是那些「只读+无副作用+逻辑简单」的触发器；必须保留在数据库侧的是「强一致性要求+跨行校验+需拦截操作」的逻辑。
可外移的典型场景：
- 审计日志类：
tr_order_after_update_audit，只向audit_log插一行，字段全来自OLD/NEW - 字段派生类：
tr_user_before_insert_set_age，仅根据birth_date算age并赋值给NEW.age - 单表状态联动类：
tr_invoice_after_update_status_notify，只发NOTIFY或写消息表，不改数据
必须保留在数据库侧的场景：
- 跨表约束类：
tr_order_before_insert_check_credit，需查customer_balance再决定是否允许插入 - 拦截型校验类：
tr_product_before_update_reject_if_sold，发现status = 'sold'就RAISE EXCEPTION - 自治事务需求类：如Oracle中用
PRAGMA AUTONOMOUS_TRANSACTION写日志，确保即使主事务回滚日志也不丢
迁移时最关键的三步实操动作
迁移不是重写，而是“解耦—验证—接管”。重点不在代码怎么写，而在如何让行为不变。
- 先停用触发器，但保留定义（注释掉或用
DISABLE TRIGGER），防止误删；在应用层新增等效逻辑，但加开关控制，默认关闭 - 开启双写模式：触发器仍执行，新应用逻辑也执行，把两者输出写入临时对比表（如
trigger_outputvsapp_output），跑历史数据回放比对 - 上线前做“断流验证”：暂停业务写入，用真实流量重放工具（如
pgbench定制脚本）批量跑10万条变更，确认两套输出完全一致，再切开关
PostgreSQL下特别要注意的陷阱
PostgreSQL的触发器模型决定了它比MySQL更难“假装外移”：AFTER触发器无法修改当前行，BEFORE触发器又无法读其他行（除非显式SELECT，但会引发快照不一致）。这意味着很多你以为“只是记个日志”的触发器，其实悄悄依赖了事务内最新快照。
例如这个触发器：
CREATE OR REPLACE FUNCTION tr_order_after_update_update_summary() RETURNS TRIGGER AS $$ BEGIN UPDATE order_summary SET total = (SELECT SUM(amount) FROM order_item WHERE order_id = NEW.id) WHERE order_id = NEW.id; RETURN NEW; END; $$ LANGUAGE plpgsql;
它看似只更新汇总表，但子查询(SELECT SUM(...))读的是当前事务已提交+未提交的可见行——搬到应用层后，若用两次独立查询（先查sum，再update），就可能读到旧快照，导致汇总值滞后。这种细节，不跑真实数据根本发现不了。
真正容易被忽略的地方，从来不是语法翻译，而是事务边界、快照可见性、以及那几行没写进文档的隐式依赖。
