IF UPDATE() 仅判断列是否出现在SET子句中，不检测实际值变化；真实变更需对比inserted/deleted表值，并妥善处理NULL及多字段场景。
IF UPDATE() 只在触发器里有效，且不反映实际值变化
IF UPDATE() 是 SQL Server 触发器中用于判断某列是否出现在 UPDATE 语句 SET 子句里的逻辑检查，**不是字段值真正发生变化的检测**。它无法区分“设为相同值”和“设为新值”。比如执行 UPDATE Employees SET Name = 'Alice' WHERE EmployeeID = 1，即使当前 Name 就是 'Alice'，IF UPDATE(Name) 仍返回 TRUE。
常见错误现象：日志表里记录了大量“变更”，但查数据发现字段值根本没变——这就是误把列被更新（语法层面）当成值被修改（语义层面）。
- 只支持在
AFTER UPDATE或INSTEAD OF UPDATE触发器中使用 - 对
INSERT和DELETE操作无效 - 不能用于存储过程、函数或普通批处理中
- 不适用于计算列、视图列或通过
DEFAULT或IDENTITY修改的列
真正捕获字段值变化：必须对比 inserted/deleted 中的值
要确认某字段“值变了”，唯一可靠方式是在触发器中显式比对 inserted 和 deleted 表对应行的字段值。SQL Server 不提供内置的“值差异检测”函数，全靠手写条件。
示例：监控 Employees.Salary 是否真实变动：
CREATE TRIGGER trg_Employees_Salary_Change
ON Employees
AFTER UPDATE
AS
BEGIN
INSERT INTO EmployeeChanges (EmployeeID, OldSalary, NewSalary, ChangeDate)
SELECT
i.EmployeeID,
d.Salary, -- 更新前
i.Salary, -- 更新后
GETDATE()
FROM inserted i
INNER JOIN deleted d ON i.EmployeeID = d.EmployeeID
WHERE i.Salary <> d.Salary -- 关键：值不等才记录
OR (i.Salary IS NULL AND d.Salary IS NOT NULL)
OR (i.Salary IS NOT NULL AND d.Salary IS NULL);
END;注意点：
- 必须处理
NULL比较，因为NULL = NULL返回UNKNOWN，直接用会漏掉NULL ↔ 非NULL变更 - 如果表有复合主键，
JOIN条件需包含全部主键列 - 避免在
WHERE中对大字段（如NVARCHAR(MAX)）做直接比较，可能引发性能抖动
想监控多个字段？别堆砌 IF UPDATE() 嵌套
有人试图这样写：
IF UPDATE(Name) BEGIN ... END IF UPDATE(Salary) BEGIN ... END
这会导致重复插入、逻辑混乱，尤其当多字段同时更新时。正确做法是：一次查询，按字段分别生成变更记录，用 UNION ALL 合并。
示例：同时监控 Name 和 Salary 的真实变化：
INSERT INTO EmployeeChanges (EmployeeID, FieldName, OldValue, NewValue, ChangeDate) SELECT EmployeeID, 'Name', CAST(d.Name AS NVARCHAR(256)), CAST(i.Name AS NVARCHAR(256)), GETDATE() FROM inserted i JOIN deleted d ON i.EmployeeID = d.EmployeeID WHERE i.Name <> d.Name OR (i.Name IS NULL AND d.Name IS NOT NULL) OR (i.Name IS NOT NULL AND d.Name IS NULL) <p>UNION ALL</p><p>SELECT EmployeeID, 'Salary', CAST(d.Salary AS NVARCHAR(256)), CAST(i.Salary AS NVARCHAR(256)), GETDATE() FROM inserted i JOIN deleted d ON i.EmployeeID = d.EmployeeID WHERE i.Salary <> d.Salary OR (i.Salary IS NULL AND d.Salary IS NOT NULL) OR (i.Salary IS NOT NULL AND d.Salary IS NULL);
要点：
- 所有字段统一转成可比较的字符串类型（如
NVARCHAR(256)），避免隐式转换失败 - 每个字段的
WHERE条件必须独立、完整，不可复用上一个字段的判断结果 - 如果审计表结构固定（如只存
OldName/NewName），就不要强行通用化；字段多且动态时，才考虑 JSON 或 EAV 模式
替代方案：CDC 或 CHANGE TRACKING 更适合生产环境
手写触发器+值对比虽精准，但维护成本高、易出错、影响 DML 性能。SQL Server 原生的 CHANGE TRACKING（轻量）或 CDC（完整）才是面向生产的选择。
它们的关键优势：
-
CHANGE TRACKING：开启后无需改表结构，用CHANGETABLE(CHANGES ...)函数查变更，开销低，但只返回主键和变更版本，不存旧值/新值 -
CDC：捕获完整变更镜像（含__$operation,__$update_mask），支持回放，但需启用代理作业、占用额外空间 - 两者都自动处理事务一致性、并发和清理，而触发器需要自己防死锁、加锁提示、控制嵌套层级
容易被忽略的一点：CDC 表名带 _CT 后缀，字段名会被重命名（如 Salary → __$start_lsn + 数据列），直接查很反直觉；第一次用务必先跑 SELECT * FROM cdc.dbo_employees_CT 看清结构再写应用逻辑。
