SQL触发器应慎用，仅用于跨表约束或审计字段维护等不可替代场景；须精简逻辑、异步处理非核心任务、避免递归与死锁，并建立日志、开关和异常捕获机制确保可观测与可熔断。
SQL 触发器在保证数据一致性、自动执行业务逻辑方面很有用，但若设计不当，极易引发性能瓶颈和隐性故障。关键在于控制触发器的执行范围、减少资源消耗、避免递归与死锁，并始终保留可追溯的干预能力。
精简触发器逻辑，避免在触发器中做重操作
触发器运行在事务上下文中，任何耗时操作（如远程调用、大表扫描、复杂计算、大量 INSERT/UPDATE）都会拖慢主 SQL 执行速度，甚至导致锁等待加剧。应只保留真正必须在行级变更瞬间完成的动作。
- 把日志记录、统计汇总、通知推送等非强一致性任务，改为异步方式（如写入消息队列或延迟作业表）
- 避免在 INSERT/UPDATE 触发器中再次查询或修改同一张表（尤其在 SQL Server 中会直接报错；MySQL 5.7+ 也限制此类操作）
- 如需关联查询，优先使用 JOIN inserted/deleted 伪表（SQL Server）或 NEW/OLD 别名（MySQL/PostgreSQL），而非重新 SELECT 主表
严格限制触发器作用范围，按需启用
不是所有场景都需要触发器。多数数据校验、默认值填充、简单状态更新，完全可用应用层逻辑、CHECK 约束、DEFAULT 约束或存储过程替代，更可控、更易测试。
- 仅在跨表约束（如订单创建时扣减库存且需检查余额）、审计字段自动维护（如 created_by、updated_at）等难以用声明式语法覆盖的场景才考虑触发器
- 对高频写入表（如日志表、实时埋点表），原则上禁用触发器；可通过应用批量写入 + 定时 ETL 补偿
- 上线前用真实负载压测：对比开启/关闭触发器时的 QPS、平均响应时间、锁等待次数
防范递归、嵌套与死锁风险
触发器可能意外激活其他触发器（如 A 表 UPDATE 触发 B 表 INSERT，B 表又有 INSERT 触发器再改 A 表），形成链式调用，轻则性能雪崩，重则事务超时或死锁。
- SQL Server 中设置 RECURSIVE_TRIGGERS OFF（数据库级），并显式检查 TRIGGER_NESTLEVEL() 避免深层嵌套
- MySQL 中通过 innodb_lock_wait_timeout 缩短等待窗口，并在触发器内加 SELECT ... FOR UPDATE SKIP LOCKED（如需安全读取）
- 所有触发器开头添加简单标记判断（例如：IF EXISTS(SELECT 1 FROM tempdb..sysobjects WHERE name='__trigger_in_progress') RETURN），配合会话级临时表或上下文信息规避重复执行
建立可观测性与快速熔断机制
生产环境中，触发器错误常表现为“SQL 突然变慢”或“某类更新失败但无明确报错”，排查成本高。必须让触发器行为可查、可停、可回滚。
- 每个触发器内强制写入轻量级执行日志表（含 event_time、table_name、trigger_name、row_count、error_msg），并设置保留周期（如 7 天）
- 为关键触发器配置开关字段（如 sys_config 表中 flag_trigger_order_audit = 0/1），应用层或 DBA 可随时禁用而不需 DDL 操作
- 在触发器中捕获异常（SQL Server 的 TRY…CATCH、MySQL 的 DECLARE HANDLER），记录错误后 RAISERROR / SIGNAL 抛出，不静默吞掉异常
不复杂但容易忽略：触发器不是“自动兜底”，而是“带权责的隐式代码”。每一次新增，都要回答三个问题——它是否不可替代？是否经过并发验证？是否留好了逃生通道？
