触发器是跨表校验、动态逻辑和自定义错误提示的必要补充，适用于CHECK约束无法处理的场景，如联查余额、历史价格比对、员工归属检查及订单频次限制；AFTER触发器用于审计与级联更新，INSTEAD OF用于拦截非法操作与视图更新；需注意语句级触发、NULL比较、事务隔离、复制环境、性能开销及显式设置ANSI_NULLS等关键细节。
触发器不是数据完整性的首选方案，但当你需要跨表校验、动态逻辑或自定义错误提示时，AFTER 和 INSTEAD OF 触发器确实能补上 CHECK 约束和外键做不到的缺口。
什么时候必须用触发器而不是CHECK约束
CHECK 约束只能引用当前行的列，无法查其他表、调用函数（如 GETDATE()）、做子查询或判断关联状态。比如以下场景就绕不开触发器：
- 插入订单时检查客户账户余额是否足够——需联查
Customers表 - 更新产品价格时禁止低于历史最低价——需查
PriceHistory表 - 删除部门前确认无员工归属——需
EXISTS检查Employees表 - 要求“同一客户当天最多下3单”——需聚合
GROUP BY customer_id, CAST(order_time AS DATE)
AFTER vs INSTEAD OF：选错类型会直接失效
AFTER 触发器在语句执行后才运行，此时数据已写入表，适合审计、通知或级联更新；INSTEAD OF 则完全替代原操作，适合在视图上实现可更新逻辑，或彻底拦截非法修改。
- 想阻止违规数据写入？必须用
INSTEAD OF+ROLLBACK，AFTER触发器里ROLLBACK虽能回滚，但已触发约束检查、可能产生死锁 - 要记录修改前后的值？
AFTER可读inserted和deleted临时表；INSTEAD OF中deleted表为空（因为原 DELETE 还没执行） - 对视图建触发器？只能用
INSTEAD OF；对内存优化表？只支持AFTER，且不能用inserted/deleted
常见陷阱：NULL、多行、事务边界
触发器天然按语句级触发，不是按行级，这点和应用层逻辑直觉相反——一个 UPDATE 影响1000行，触发器只执行一次，inserted 表里有1000条记录。
- 别写
IF (SELECT COUNT(*) FROM inserted) > 1 ...这种判断——它永远成立，应直接用集合操作，比如WHERE id IN (SELECT id FROM inserted) - 涉及
NULL比较时务必用IS NULL或IS NOT NULL，= NULL永远返回UNKNOWN，导致校验失效 - 触发器内调用存储过程或链接服务器，可能隐式升级事务隔离级别，引发阻塞；建议把复杂逻辑抽到独立过程，用
EXECUTE AS显式控制权限 -
NOT FOR REPLICATION必须加在复制环境的触发器上，否则同步操作会误触发，造成数据不一致
性能与维护成本的真实代价
每个触发器都增加语句执行路径长度，尤其当 inserted/deleted 表很大时，全表扫描或缺失索引会导致严重延迟。更隐蔽的问题是调试困难——错误不会直接报在应用SQL里，而是藏在事务回滚堆栈中。
- 上线前务必在生产级数据量下压测，重点看
sys.dm_exec_trigger_stats的execution_count和total_elapsed_time - 避免在触发器里写
PRINT或RAISERROR带状态码的提示——应用可能捕获不到，改用THROW 50000, '业务规则冲突', 1 - 所有触发器必须带
SCHEMABINDING（如果逻辑允许），防止底层表结构变更后触发器意外失效 - 最易被忽略的一点：触发器不继承父表的
ANSI_NULLS或QUOTED_IDENTIFIER设置，创建时必须显式指定，否则可能在某些客户端连接下静默失败
