sql触发器适合封装审计日志、状态联动、字段派生、约束增强等数据驱动且需强制同步执行的业务规则，应避免用于通用逻辑或远程调用，优先考虑存储过程、应用层处理等替代方案。
SQL 触发器适合封装那些与数据变更强耦合、必须同步执行且跨应用统一的业务规则，比如审计日志、状态自动更新、数据一致性校验等。它不是通用业务逻辑层，过度使用会降低可读性、增加调试难度，并可能引发性能和事务问题。
哪些场景适合用触发器封装业务逻辑
触发器的价值在于“数据驱动”和“强制执行”，适用于以下几类典型场景：
- 操作留痕：用户表更新时，自动向 audit_log 表插入操作人、时间、旧值/新值，无需每个应用代码重复写日志逻辑。
- 状态联动：订单表中 status 字段更新为 'shipped' 时，自动将关联的 inventory 表中对应商品 quantity 减 1，保证库存与订单状态实时一致。
- 字段派生：在插入或更新用户记录时，自动根据 birth_date 计算 age 并写入（注意：更推荐计算列或视图，仅当需物理存储且逻辑固定时用触发器）。
- 约束增强：CHECK 约束无法跨表，但可用 BEFORE INSERT/UPDATE 触发器检查“客户余额不能低于其未结订单总额”，实现复杂业务级完整性控制。
编写触发器的关键实践原则
避免把触发器写成“黑盒业务服务”，应聚焦数据层面职责，保持轻量、明确、可预测：
- 只做必要动作：一个触发器只解决一个问题，例如“记录修改日志”或“更新统计计数”，不要在一个触发器里既写日志又改状态再发消息。
- 慎用事务内远程调用：禁止在触发器中调用外部 API、发送邮件或写文件——这些操作不可回滚、易超时、破坏事务原子性。
- 区分 BEFORE 和 AFTER 语义：需要校验或修改即将插入/更新的行内容（如标准化手机号格式），用 BEFORE；需要依赖已提交的新值做后续处理（如更新汇总表），用 AFTER。
- 显式处理多行影响：INSERT INTO ... SELECT 或批量 UPDATE 可能一次触发多行，触发器逻辑必须兼容 ROW_COUNT() > 1 的情况，避免只取 FIRST 或硬编码 LIMIT 1。
替代触发器的更优方案（先考虑这些）
多数业务逻辑更适合放在应用层或数据库对象层，而非触发器：
- 存储过程封装：将“创建订单+扣库存+生成日志”整套流程封装为一个带事务的存储过程，由应用显式调用，逻辑集中、可测试、可追踪。
- 应用服务层统一处理：使用 ORM 中间件拦截 save() 方法，或在领域服务中统一编排，便于加入缓存、异步通知、权限校验等扩展能力。
- 物化视图或定时汇总表：对报表类统计需求（如“各门店昨日销量”），用定时任务或物化视图更新，比在每笔销售触发器中实时累加更稳定高效。
- 数据库约束和默认值：非空、唯一、外键、DEFAULT CURRENT_TIMESTAMP 等原生机制，比触发器更高效、更标准，应优先使用。
调试与维护注意事项
触发器隐式执行，容易成为故障盲区，上线前和运行中需特别关注：
- 命名规范清晰：例如 tr_orders_after_update_status_shipped、tr_users_before_insert_normalize_phone，让 DBA 一眼理解作用范围和时机。
- 日志开关可控：生产环境默认关闭触发器内 debug 日志；可通过配置表或 session 变量动态启用，避免日志写满磁盘。
- 版本化管理：触发器 DDL 脚本纳入数据库迁移工具（如 Flyway、Liquibase），与应用代码一同版本控制、灰度发布。
- 监控执行耗时：对高频表的触发器，定期查 information_schema.triggers 配合 performance_schema 分析平均延迟，防止拖慢主 SQL。
