SQL触发器应仅用于轻量级数据库级副作用，如生成UUID、记录时间戳、写审计日志；严禁替代应用逻辑、执行耗时操作、破坏事务边界或模拟约束。
SQL 触发器不是万能的“自动补丁”，用错地方反而拖慢系统、引发死锁、掩盖业务逻辑缺陷。关键要分清它该做什么、不该做什么，再针对性优化。
误用一：用触发器替代应用层校验和业务逻辑
比如在订单表上加 INSERT 触发器，自动计算折扣、更新库存、发通知——看似省事，实则把本该由应用控制的流程硬塞进数据库，导致逻辑分散、难以测试、无法回滚部分操作。
优化建议：
- 校验类逻辑（如金额非负、邮箱格式）优先放在应用层，失败时直接拦截，避免无谓的 SQL 执行和事务开销
- 跨表一致性（如“下单扣库存”）应由应用在单个事务中完成，确保原子性可追踪；触发器仅用于极少数强耦合、必须数据库级兜底的场景（如审计日志写入）
- 若必须用触发器做计算，确保不调用外部服务、不查大量数据、不触发其他触发器（防止级联）
误用二：在触发器里执行耗时操作或复杂查询
常见做法是在 UPDATE 用户表触发器中，实时统计该用户所有订单总金额并写回用户表字段。这会导致每次更新用户基本信息（如改昵称）都去扫描全部订单，严重拖慢响应。
优化建议：
- 避免在触发器中 SELECT 大量数据或 JOIN 多张大表；统计类需求改用物化视图、定时任务或应用缓存
- 如需实时汇总，考虑用增量更新方式：只查刚变动的那条订单，用 +\- 方式修正总计字段，而非全量重算
- 对高频更新表，禁用非必要触发器；可通过开关字段或配置表动态控制触发器是否启用
误用三：忽略触发器执行顺序与事务边界
多个触发器作用于同一事件（如两个 AFTER INSERT 触发器），执行顺序依赖创建顺序，但未显式声明依赖关系；又或在触发器中提交/回滚事务，破坏外层事务一致性。
优化建议：
- 一个表同一事件类型（如 AFTER INSERT）只保留一个触发器，内部用 IF/ELSE 拆分逻辑，避免顺序不可控
- 绝对禁止在触发器中使用 COMMIT 或 ROLLBACK（除特殊自治事务场景，且需明确注释）
- 对必须按序执行的逻辑，改用存储过程封装，由应用统一调用，而非依赖触发器隐式触发
误用四：用触发器实现“伪外键”或“伪约束”
例如因历史原因无法加外键，就在子表 INSERT 触发器里手动查父表是否存在对应记录。这种做法无法被查询优化器识别，不参与执行计划生成，且报错信息模糊（显示触发器错误而非约束冲突）。
优化建议：
- 优先使用原生约束（FOREIGN KEY、CHECK、UNIQUE），它们高效、标准、可被优化器利用
- 只有当约束条件涉及函数、跨库或动态规则时，才考虑触发器，并务必配合注释说明“此处替代约束，因XXX限制”
- 触发器内校验失败应使用 RAISERROR（SQL Server）或 SIGNAL（MySQL 5.5+）抛出明确错误码和消息，方便应用捕获处理
触发器真正的价值在于轻量、可靠、数据库级的副作用控制——比如自动生成 UUID、记录变更时间戳、写审计日志。把它当“胶水”用，而不是“大脑”用，系统才会稳得住、查得快、改得清。
