触发器报错时事务会回滚但日志可能为空，必须在每个after/instead of触发器中手动添加try/catch并写入独立数据库的日志表，同时校验instead of逻辑完整性。
触发器报错时事务会回滚，但日志里可能什么都没有
SQL Server 触发器运行在主 DML 语句的同一事务中，INSERT、UPDATE 或 DELETE 失败时，整个事务（含触发器逻辑）会回滚。这意味着：如果触发器里抛出错误（比如向不存在的表 INSERT），主操作失败，但默认不会留下任何执行痕迹——sys.dm_exec_trigger_stats 不记录失败，ERROR_LOG 也不自动写入（除非显式 RAISERROR 并配置了错误日志捕获）。
- 触发器内未处理的异常（如引用空列、除零、外键冲突）会导致主语句失败，但不生成独立错误日志条目
-
sys.fn_trace_gettable和 SQL Server Profiler 默认不捕获触发器内部的语句级错误，只记录顶层 DML - 即使启用
QUERY_STORE，它也只跟踪查询性能，不记录触发器是否执行或失败
必须手动加 TRY/CATCH + 日志表写入
监控触发器异常唯一可靠的方式，是在触发器代码里主动捕获并落库。不能依赖外部工具“监听”它。
- 所有
AFTER触发器开头必须包一层BEGIN TRY ... END TRY BEGIN CATCH ... END CATCH -
CATCH块中调用INSERT INTO TriggerErrorLog，至少记录：ERROR_NUMBER()、ERROR_MESSAGE()、ERROR_LINE()、触发器名、当前GETDATE() - 避免在
CATCH中再执行可能失败的操作（如调用远程服务、写文件），否则错误会被吞掉 - 示例关键片段：
CREATE TRIGGER trg_EmployeeDeptChange ON Employees AFTER UPDATE AS BEGIN TRY ... INSERT INTO EmployeeAudit (...) SELECT ... FROM inserted i JOIN deleted d ... END TRY BEGIN CATCH INSERT INTO TriggerErrorLog (TriggerName, ErrorNumber, ErrorMessage, ErrorLine, LogTime) VALUES ('trg_EmployeeDeptChange', ERROR_NUMBER(), ERROR_MESSAGE(), ERROR_LINE(), GETDATE()); END CATCH
别把日志表和业务表放同一个数据库
如果触发器因日志表不可写（比如磁盘满、权限丢失、被误删）而失败，会连带导致所有关联 DML 失败——形成雪崩。
- 日志表应建在独立数据库（如
DBA_Monitoring），且确保触发器账户对该库有INSERT权限 - 日志表结构尽量精简：
ID（IDENTITY）、TriggerName（NVARCHAR(128)）、ErrorNumber（INT）、ErrorMessage（NVARCHAR(MAX)）、LogTime（DATETIME2） - 定期归档或清理日志表，避免其自身成为性能瓶颈（特别是高频触发场景）
INSTEAD OF 触发器更容易静默失败
INSTEAD OF 触发器替代原操作执行，如果里面漏写 INSERT/UPDATE 语句，数据就真的没改——而且不报错。这种“成功假象”比报错更危险。
- 检查
INSTEAD OF触发器是否覆盖了所有预期路径（比如IF @some_condition分支下忘了写实际 DML） - 对关键
INSTEAD OF触发器，强制在末尾加校验：IF NOT EXISTS (SELECT 1 FROM inserted)就RAISERROR报告逻辑缺失 - 测试时务必验证“什么都没发生”的情况：用最小化数据跑一遍，确认变更确实落地
INSTEAD OF 的空操作风险。
