SQL触发器适合封装审计日志、状态级联、字段派生、简单约束增强等轻量确定的数据库内操作；不适合复杂流程、外部调用、递归修改或依赖应用上下文的逻辑。
SQL 触发器适合封装那些与数据变更强绑定、需自动执行且跨应用统一的业务规则，比如审计日志记录、状态联动更新、数据一致性校验等；但它不适合承载复杂流程、外部调用或需要事务控制灵活性的逻辑。
哪些业务场景适合用触发器封装
触发器的核心价值在于“数据一变，逻辑即响”，适用于以下几类轻量、确定、数据库内可完成的操作：
- 操作留痕：用户表更新时，自动向 audit_log 表插入变更前/后值、操作人、时间戳，无需每个业务接口重复写日志代码
- 状态级联：订单表 status 改为 'shipped' 时，自动将对应物流单的 is_dispatched 设为 true，避免应用层漏处理
- 字段派生：在插入或更新商品表时，根据 price 和 discount 自动计算 final_price，保证视图或查询结果始终一致
- 简单约束增强：如禁止删除已被引用的分类（检查 category_id 是否仍在 product 表中存在），比外键 CASCADE 更灵活
哪些逻辑坚决不该放进触发器
一旦触发器开始做这些事，就会迅速演变成维护噩梦：
- 调用外部服务：发送短信、调用 HTTP API、写 Kafka —— 触发器内网络超时或失败会导致事务回滚不可控
- 复杂分支判断：涉及多表关联查询 + 多条件嵌套 + 不同业务线规则差异，调试难、测试难、上线风险高
- 修改触发它的同一张表：可能引发递归触发（MySQL 默认禁用，但 PostgreSQL 需显式控制），极易死锁或无限循环
- 依赖应用上下文：比如“当前登录用户ID”“请求来源渠道”这类信息，触发器无法直接获取，硬塞 session 变量易出错
写触发器的关键实践建议
不是不能用，而是要用得克制、清晰、可维护：
- 命名规范明确用途：如 tr_order_after_update_status_audit，而非 tr1 或 after_upd
- 只做一件事：一个触发器对应一个明确目标，不混入日志+校验+通知多个职责
- 优先使用 AFTER 而非 BEFORE：确保主语句已成功执行，避免因触发器异常导致业务 SQL 失败；仅当需拦截操作（如拒绝非法更新）才用 BEFORE
- 在注释里写清业务含义：比如 “此触发器保障：订单发货后，对应库存占用记录 must_release = 0”，让后续接手人一眼看懂 Why
- 配合单元测试（用 SQL 脚本验证）：插入测试数据 → 检查触发效果 → 断言结果表状态，不依赖应用启动
替代方案比触发器更合适的情况
当业务逻辑稍有复杂度上升，就该主动降级到更可控的层级：
- 存储过程 + 应用调用：把校验、更新、日志打包成一个过程，由应用显式调用，事务边界清晰，错误可捕获可重试
- 应用层领域服务：用 OrderService.ship() 封装发货全流程，含库存扣减、物流创建、消息推送，逻辑集中、可观测、可灰度
- 数据库 CDC + 消息队列：用 Debezium 监听 binlog，将变更发到 Kafka，由独立消费者处理后续动作，解耦、异步、可扩展
触发器不是银弹，是工具箱里一把窄刃小刀——切薄片快准稳，砍粗枝容易崩口。用对地方，它默默扛下重复劳动；用错位置，它会悄悄拖慢整个系统。
