SQL触发器仅适用于轻量级数据校验与衍生写入，禁用于替代应用逻辑、复杂流程或跨库操作；须避免调用外部服务、多表JOIN更新、标量假设编程及替代原生约束。
SQL 触发器不是万能的“自动补丁”，用错地方反而拖慢系统、引发死锁、掩盖业务逻辑缺陷。关键在于明确触发器的边界：它适合做轻量级、强一致性的数据校验与衍生写入，不适合替代应用层逻辑、处理复杂流程或跨库操作。
误用一：在触发器里调用存储过程或外部服务
常见场景是订单插入后，在 INSERT 触发器中调用 send_email_proc() 或调用链接服务器更新其他数据库。这会把事务范围意外扩大，导致锁等待加剧、超时风险上升，且违反了数据库层只管数据状态的原则。
- 改用异步解耦：触发器只写一条消息到通知表（如 order_notify_queue），由独立作业（如 SQL Server Agent Job 或应用定时任务）轮询并发送邮件
- 若必须同步响应，把该逻辑上移至应用层，在事务提交前统一处理，确保可控性和可测试性
- 绝对避免在触发器中使用 OPENQUERY、xp_cmdshell、CLR 集成等高风险扩展功能
误用二：触发器内执行多表 JOIN 更新或递归计算
例如在员工表 UPDATE 触发器中，遍历整个部门树重新计算每个下属的累计薪资。这类操作随数据量增长呈指数级变慢，还可能因触发链（A→B→A）引发嵌套触发甚至堆栈溢出。
- 改用物化视图或计算列：对固定维度（如直属上级ID、部门层级）用 PERSISTED 计算列实时维护
- 对统计类字段（如部门总薪资），改用定期批处理刷新（如每晚跑一次 UPDATE + GROUP BY），配合 last_modified 时间戳过滤增量
- 启用触发器递归选项（RECURSIVE_TRIGGERS）前务必确认必要性，并加深度限制和短路条件（如仅当 salary 字段实际变化才执行）
误用三：忽略多行操作（SET-based）导致逻辑错误
用 IF EXISTS(SELECT ...) 或 SELECT @var=... 这类标量假设编写触发器，会在线上批量导入（如 INSERT INTO emp SELECT ... FROM staging）时只处理第一行，其余数据静默丢失校验或产生脏数据。
- 始终面向 inserted/deleted 表集合编程：用 MERGE、UPDATE ... FROM inserted 或 EXISTS (SELECT 1 FROM inserted i WHERE i.id = t.id) 替代单值变量
- 校验类逻辑（如禁止负库存）用 NOT EXISTS + LEFT JOIN 检查整批数据，而非逐行判断
- 测试阶段必须用至少 2 行以上的 INSERT/UPDATE/DELETE 语句验证触发器行为
误用四：用触发器替代约束或默认值
比如用 BEFORE INSERT 触发器给 create_time 赋 GETDATE()，或用触发器检查 email 格式，完全可以用 DEFAULT GETDATE() 和 CHECK CONSTRAINT（email LIKE '%_@__%.__%'）更高效、更透明地实现。
- 优先使用原生约束：NOT NULL、UNIQUE、CHECK、FOREIGN KEY、DEFAULT——它们性能更好、报错更明确、工具识别更完整
- 触发器只用于约束无法表达的逻辑：如“同一客户当天最多下3单”，需关联历史订单表判断
- 所有触发器必须配对应注释和文档，说明其不可绕过性、事务影响及禁用场景（如数据迁移时临时禁用）
不复杂但容易忽略：上线前用实际批量数据压测触发器执行时间，监控 sys.dm_exec_trigger_stats 中的 execution_count 和 total_elapsed_time；日常运维中定期审查触发器是否存在冗余、嵌套或长期未修改的“僵尸触发器”。
