SQL触发器易引发数据一致性风险、性能隐患及维护困难，应优先用显式逻辑替代，仅在必要时用于审计日志或约束校验。
SQL触发器虽能自动响应数据变更，但容易引发隐性问题。关键在于它绕过常规业务逻辑执行，且调用链不透明，一旦设计不当，会直接破坏数据一致性或拖垮性能。
数据一致性风险：隐式修改难追踪
触发器在INSERT/UPDATE/DELETE时自动运行，可能悄悄修改其他表、重置字段、甚至递归触发自身。开发人员若未查阅触发器定义，仅看应用代码，会误判数据来源和更新逻辑。
- 例如：用户表更新时，触发器同步更新统计表的“最后登录时间”，但应用层也有一段逻辑做同样操作，两者冲突导致值被覆盖
- 级联更新未加事务控制，主表成功、从表失败，造成部分写入，状态不一致
- 触发器中调用存储过程或外部函数，而该函数抛异常但未被捕获，导致整个事务回滚却不报明确错误
性能隐患：不可见的执行开销
触发器运行在SQL引擎内部，不经过网络、不走连接池，但每行变更都强制执行——尤其在批量操作（如导入10万条记录）时，可能把O(1)操作放大为O(n)甚至O(n²)。
- 在UPDATE语句上定义FOR EACH ROW触发器，更新1万行即执行1万次查询或计算
- 触发器内含SELECT子查询且未走索引，全表扫描反复发生
- 多个触发器嵌套（如A触发B，B又触发C），执行路径爆炸式增长，监控工具难以定位瓶颈
维护与调试困难：缺乏上下文与可观测性
触发器没有调用栈、不记录日志（除非显式写入）、不参与版本控制（常游离于代码库之外），上线后出问题往往只能靠“猜+禁用”来排查。
- 数据库迁移或重建时，触发器容易遗漏，导致新环境行为不一致
- 测试环境未启用触发器，功能测试通过，生产环境却因触发器逻辑出错而失败
- 审计日志只记录原始DML语句，不体现触发器引发的衍生变更，追责和回溯成本高
替代方案更可控：优先考虑显式逻辑
除非强实时性+跨系统耦合无法避免，否则应尽量用应用层事务或定时任务替代触发器。
- 将触发逻辑提取为独立服务接口，在业务代码中显式调用，便于单元测试和埋点监控
- 对统计类场景，改用物化视图或增量聚合任务（如Flink CDC + Kafka + Sink），延迟可控、可重放
- 必须用触发器时，限定仅用于简单审计日志（INSERT INTO audit_log…）或约束校验（RAISERROR终止非法操作），禁用跨表修改和复杂计算
不复杂但容易忽略：上线前务必检查触发器是否启用、是否重复创建、是否与ORM框架的乐观锁或自增逻辑冲突。
