AFTER UPDATE触发器是实现变更审计日志最常用可靠的方式，它在更新提交后触发，通过比对INSERTED和DELETED表精准捕获字段级变化，并需注意NULL安全、类型兼容、事务轻量及索引优化。
SQL 的 AFTER UPDATE 触发器是实现变更审计日志最常用、最可靠的方式之一，核心在于：它在数据更新成功提交后自动触发，能安全读取 INSERTED（新值）和 DELETED（旧值）两个临时表，从而准确捕获字段级变化。
明确审计目标再设计日志结构
不是所有字段都需要记录。先确定业务关键字段（如金额、状态、负责人、生效时间等），再决定日志表至少包含：操作时间、操作人（需应用层传入或从上下文获取）、表名、主键值、字段名、旧值、新值、操作类型（UPDATE）。避免直接记录整行，而是按字段差异逐条插入日志，便于后续查询与比对。
- 日志表建议用独立 schema（如
audit）隔离，避免影响业务表性能 - 主键值字段要适配原表（如
OrderId INT或UserId UNIQUEIDENTIFIER），不可统一用 varchar - 旧值/新值字段推荐用
NVARCHAR(MAX)并配合CONVERT(NVARCHAR, ...)统一转换，兼容字符串、数字、日期等类型
用 INSERTED/DELETED 精准识别变更字段
AFTER UPDATE 触发器中，INSERTED 和 DELETED 表结构与原表一致，且行数相同（一对一）。不能假设“只要 UPDATE 就一定有变化”，必须显式比对字段值。例如审计 Orders 表的 Status 和 TotalAmount：
- 用
INNER JOIN INSERTED i ON d.OrderId = i.OrderId关联两表 - 用
WHERE i.Status != d.Status OR i.TotalAmount != d.TotalAmount过滤出真实变更的行 - 对每个变更字段单独 INSERT 一条日志（可用 UNION ALL 或循环逻辑，但推荐静态 SQL 避免动态拼接）
处理 NULL 值与数据类型兼容性
直接用 = 比较 NULL 会返回 UNKNOWN，导致漏记录；直接用 CONVERT 转换某些类型（如 datetime2）可能截断精度。稳妥做法是：
- 字段比对改用
ISNULL(i.Status, '') != ISNULL(d.Status, '')或更严谨的NOT (i.Status = d.Status OR (i.Status IS NULL AND d.Status IS NULL)) - 值转字符串统一用
CONVERT(NVARCHAR(4000), value, 126)（126 格式对 datetime/datetime2 友好） - 对 XML、GEOMETRY 等特殊类型，可先判断
TYPE_ID，再跳过或转为 base64 字符串
注意事务边界与性能影响
AFTER UPDATE 触发器运行在原 UPDATE 事务内，失败会导致整个更新回滚——这是保障一致性的优势，但也意味着日志写入不能成为瓶颈：
- 避免在触发器里调用远程服务、发邮件、查大表或写多张日志表
- 日志表建议不建过多索引，但至少在
(TableName, PrimaryKeyValue, OperationTime)上建非聚集索引以加速常见查询 - 高并发场景下，可考虑将日志暂存到内存表（SQL Server 2014+）或使用 Service Broker 异步落盘，但需权衡可靠性与复杂度
触发器不是万能的，但它稳定、可控、无需修改应用代码。只要设计时盯住字段差异、NULL 安全、类型兼容和事务轻量这四个关键点，就能构建出真正可用的变更审计能力。
