很多人第一次写 SQL Server 审计触发器，重点都放在语法能不能跑通，结果上线后才发现日志缺字段、漏记录，甚至一批量更新就失真。真正决定审计是否可用的，不是 CREATE TRIGGER 这几个字，而是你能不能把新旧值、操作人、多行更新和递归风险都处理完整。
下面就按实际排查思路来拆：先确认为什么必须选 AFTER UPDATE，再看 inserted/deleted 该怎么联结，接着处理 NULL 比较和字段变更判断，最后落到日志表设计与触发器避坑上。看完你可以直接判断一段审计触发器到底是“能跑”，还是“真的能审”。
为什么审计触发器必须用 AFTER UPDATE
在 SQL Server 2019 中，UPDATE 审计触发器应该使用 AFTER UPDATE，而不是 INSTEAD OF UPDATE。
原因很直接：INSTEAD OF UPDATE 会拦截原始更新语句，后续更新逻辑需要你自己重写。一旦重放逻辑不完整，就可能出现数据没改全、日志没记全，甚至原始业务被破坏。相比之下，AFTER UPDATE 只会在原语句成功执行后触发，这时 inserted 和 deleted 中保留的才是可信的新旧值。
先搞清楚 inserted 和 deleted 分别是什么
inserted保存更新后的新行集合deleted保存更新前的旧行集合- 两者的结构都与目标表完全一致
这里有个常见误区：不要把它们当成“单行变量”。只要是批量更新，inserted 和 deleted 就一定是多行结果集。
正确写法是按主键完整 JOIN 新旧行
审计日志要知道“同一行改前改后分别是什么”，核心就是把 inserted 和 deleted 正确对应起来。不能只写 SELECT * FROM inserted 单独读取，因为这样拿到的只是更新后的结果，无法形成可靠的前后对照。
典型写法如下：
INSERT INTO audit_log (...)
SELECT i.*, d.*, SYSTEM_USER, GETDATE()
FROM inserted i
INNER JOIN deleted d ON i.id = d.id如果目标表使用复合主键，联结条件必须完整覆盖所有键列，例如：
ON i.order_id = d.order_id AND i.line_no = d.line_no这一步不能偷懒。只要 JOIN 条件漏了一部分主键，日志就可能把不同行错配到一起，最后看起来“有记录”，实际已经不可追溯。
怎样判断字段是否真的被改过
很多审计遗漏都出在字段比较上，尤其是涉及 NULL 时。表面看只是一个条件表达式，实际却会直接影响日志完整性。
不要直接用 != 比较带 NULL 的字段
像下面这种写法就有隐患：
i.Price != d.Price如果任一值为 NULL，结果就是 UNKNOWN，而不是你以为的 true/false。触发器条件因此失效，审计记录会被静默漏掉，这也是最难排查的一类问题。
UPDATE() 和值变化判断不是一回事
如果你的需求是“只要 SQL 语句里动到了某列，就记审计”，可以使用内置函数：
UPDATE(Price)UPDATE() 判断的是该列是否出现在本次 UPDATE 语句中，即使它被设成 NULL，或者设成与原值相同的内容，也会返回命中。
但如果你要的是“只有值真的变了才记录”，那就还得做一次安全比较。常见写法是配合 ISNULL 或 COALESCE：
ISNULL(i.Price, -1) != ISNULL(d.Price, -1)这种方式的重点不在于 -1 这个具体值，而在于你要选一个不会与业务真实值冲突的替代值，用来把 NULL 比较转换成可判断的普通表达式。
日志表怎么设计，才撑得住真实审计
如果日志表里只有 table_name、action_time、user 这类概要信息，那它更像操作痕迹，而不是可追溯的审计记录。真正查问题时，你需要知道的是：哪一列被改了、原值是什么、新值又是什么。
建议保留这些关键字段
- 原始表需要审计的列，分别保存为
_old/_new两组字段 - 操作类型，例如
UPDATE - 修改字段列表，例如
modified_columns varchar(max) - 操作人，例如
SYSTEM_USER或ORIGINAL_LOGIN() - 操作时间，例如
GETDATE()
这样设计后，日志才能支持类似“Price 从 199.00 改成了 249.00”这样的回溯需求。
插入日志必须按集合处理，不能按单行思路写
批量更新时，inserted 和 deleted 都是多行数据，因此日志写入必须是集合操作。不要用下面这种标量赋值方式：
DECLARE @id INT;
SELECT @id = id FROM inserted这种写法只会拿到某一行结果，批量更新时天然丢数据。
另一个高频错误是把 inserted 和 deleted 直接 SELECT * 插入日志表。日志表和源表字段通常不会完全一致，列顺序和数量只要不匹配，就会直接报错。因此在 INSERT INTO audit_log (...) 中必须显式列出目标列，SELECT 也要一一对应。
为什么 AFTER 触发器里不要再 UPDATE 原表
SQL Server 默认允许在 AFTER UPDATE 触发器中再次对同一张表执行 UPDATE。从语法上看可行，但在审计场景里风险很高，因为它很容易形成递归触发。
触发链一旦出现自我调用，就可能不断重复，直到达到嵌套层级上限。SQL Server 默认上限是 32，届时会报出：
Maximum stored procedure nesting level exceededAFTER 审计触发器里哪些操作相对安全
- 向日志表执行
INSERT - 按业务需要
UPDATE其他关联表，例如库存表 - 使用
RAISERROR或THROW抛出异常
如果你确实需要回写原表，比如自动补全 updated_by，更合理的方向是改用 INSTEAD OF UPDATE，但代价是必须手动重放整个更新逻辑，复杂度和出错概率都会明显上升。
TRIGGER_NESTLEVEL() 可以用于检查当前嵌套深度，但它更适合作为兜底保护，而不是常规设计思路。能从设计上避免递归，就不要把问题留给运行时。
写完触发器后，至少核对这几件事
一段 UPDATE 审计触发器是否可靠，最后可以回到几个最实际的问题：
- JOIN 条件是否完整覆盖了所有主键
NULL比较是否使用了安全写法- 批量更新时是否仍然按集合方式插入日志
- 日志表能否看出具体字段的前后差异
- 触发器内部是否意外更新了原表，导致递归风险
SQL Server 2019 的审计触发器真正难的地方，一直都不是语法，而是这些细节能不能经得起批量更新、空值场景和后续追查。只要这几项没处理好，日志即使每天都在写，也很可能只是“看着有，实际不能用”。
