SQL 数据一致性触发器的核心目标是确保数据在变更时自动满足业务规则，避免应用层遗漏校验导致脏数据。关键在于精确定义触发时机、最小化影响范围、避免递归和死锁。
明确触发时机与作用域
触发器应在最接近数据变更的时刻生效，优先选择 AFTER INSERT/UPDATE/DELETE 而非 INSTEAD OF（除非需完全接管逻辑）。对单行操作敏感的场景（如余额不能为负），务必使用 FOR EACH ROW（PostgreSQL/Oracle）或通过 inserted/deleted 临时表（SQL Server）逐行校验；批量更新时避免在触发器内写循环，应改用集合操作判断整体约束是否被破坏。
- INSERT 触发器重点校验默认值填充、唯一性前置检查、状态初始化
- UPDATE 触发器必须对比 OLD 和 NEW 值，仅当关键字段变化时执行校验（例如只在 price 或 quantity 变更时重算库存）
- DELETE 触发器需检查级联依赖（如删除客户前确认无未结订单），而非简单禁止删除
规避常见陷阱：递归、性能与事务耦合
触发器默认处于当前事务中，失败将直接回滚整个操作——这是保障一致性的优势，也是风险来源。必须防止隐式递归：比如 UPDATE 订单表触发器又去 UPDATE 同一订单的更新时间戳，可能再次触发自身。SQL Server 需设 RECURSIVE_TRIGGERS OFF；PostgreSQL 可用 TG_LEVEL = 'ROW' 结合条件跳过重复触发。
- 禁用触发器内调用存储过程执行 DML 操作（尤其涉及同一张表），极易引发死锁或无限循环
- 避免在触发器中查询大表或加锁范围过宽的操作（如 SELECT ... FOR UPDATE 全表扫描）
- 日志记录类操作建议异步化（写入消息队列或延迟表），不阻塞主事务
用声明式约束替代部分触发器逻辑
能用 CHECK 约束、外键、唯一索引、DEFAULT 解决的问题，绝不写触发器。例如“订单金额 ≥ 0”用 CHECK 最高效，“用户邮箱唯一”用唯一索引比触发器快十倍且支持并行。
- CHECK 约束可跨字段（如 start_date ≤ end_date），但无法引用其他表数据
- 外键自带级联动作（CASCADE/SET NULL），比 DELETE 触发器更可靠
- 计算列（如 PERSISTED 列）或生成列（GENERATED ALWAYS AS）可替代简单派生字段维护逻辑
测试与监控要点
触发器难以单元测试，必须覆盖多并发场景：模拟两个会话同时修改同一行、批量导入触发大量触发器执行、长时间事务中触发器等待锁等。上线后重点关注：触发器执行耗时（sys.dm_exec_trigger_stats）、阻塞链、tempdb 使用量激增（因 inserted/deleted 表存放内存）。
- 用真实业务数据做压力测试，观察触发器是否成为慢查询瓶颈
- 定期审计触发器代码，移除已废弃的校验逻辑（如老版本才需的格式转换）
- 对核心表触发器添加轻量级日志（如写入专用 audit_log 表），仅记录失败事件和关键字段变化
不复杂但容易忽略。
