SQL Server默认不记录“谁、何时、改了什么值”，需主动启用审计或创建AFTER触发器；事务日志仅用于恢复，不含用户信息和字段级变更；审计功能可记录操作行为但不存前后值；触发器是唯一可靠捕获细粒度变更的方式。
直接说结论：SQL Server 本身不记录“谁、什么时候、改了什么值”这种细粒度操作日志，除非你主动启用审计功能或写触发器——系统默认日志（如事务日志、错误日志）不保存用户身份和字段级变更内容。
SQL Server 默认日志里根本查不到“谁改的”
很多人第一反应是翻 sys.fn_dblog() 或事务日志备份，但这些只存页级物理操作（比如 LOP_MODIFY_ROW），不含登录名、应用名、SQL语句原文，更不会告诉你 Salary 从 8000 变成了 8500。哪怕开了 QUERY_STORE，它也只记执行计划和耗时，不记 DML 修改内容。
常见错误现象：用 DBCC LOG 或第三方工具解析日志，结果看到一堆 LOP_BEGIN_XACT 和 LOP_COMMIT_XACT，却找不到用户名和字段值——不是工具不行，是日志本身就没存。
- 事务日志设计目标是崩溃恢复，不是审计
-
sys.dm_exec_sessions和sys.dm_exec_requests是实时视图，断开连接后数据就消失 - Windows 安全日志只记录登录/登出，不记录数据库内操作
AFTER INSERT/UPDATE/DELETE 触发器是唯一可控的“现场抓包”方式
想可靠捕获“谁、何时、改了哪条、前后值”，必须在表上建 AFTER 触发器，利用 inserted 和 deleted 虚拟表做比对。不能用 BEFORE（SQL Server 不支持），也不能只靠 IF UPDATE(col)——它只看 SET 里有没有列名，不管值变没变。
实操关键点：
- 用
ORIGINAL_LOGIN()或SUSER_SNAME()拿登录账号，别用SYSTEM_USER（可能被 SET USER 覆盖） - 时间戳统一用
SYSDATETIME()，别用GETDATE()（精度低且受会话 SET 影响） - 敏感字段比对必须显式处理 NULL：
ISNULL(i.Salary, -1) ISNULL(d.Salary, -1)比i.Salary d.Salary OR i.Salary IS NULL XOR d.Salary IS NULL更安全 - 日志表主键必须是自增
ID INT IDENTITY，别用业务字段（比如EmployeeID）当主键，否则同一条记录多次修改会冲突
SQL Server 审计功能（Server Audit）能记“谁、何时、干了什么”，但不记“改前改后”
如果你只需要知道“张三在 2026-05-19 11:23:45 执行了 UPDATE Employees SET Name='Bob' WHERE ID=101”，那开启 SERVER AUDIT + DATABASE AUDIT SPECIFICATION 最省事，性能开销比触发器低得多。
但它有硬限制：
- 不记录旧值和新值，只记语句文本（可能被参数化后变成
UPDATE t SET c = @p1） - 无法区分“实际值变了”和“SET 了但值一样”，日志里全是重复记录
- 审计文件默认存 Windows Event Log 或二进制 .sqlaudit 文件，查起来不如表直观（得用
sys.fn_get_audit_file()） - 企业版才支持精细到列的审计（
AUDIT ON OBJECT::Employees (Name)），标准版只能按语句类型（INSERT/UPDATE/DELETE）粗粒度开关
别踩“多字段更新时漏判 NULL”的坑
监控多个敏感字段（比如 IDCard, BankAccount, Email）时，最常翻车的是 NULL 处理逻辑写错。例如下面这段代码看似合理，实则漏掉所有 NULL ↔ 非 NULL 场景：
WHERE i.IDCard != d.IDCard
正确写法必须覆盖三种情况：
i.IDCard != d.IDCardi.IDCard IS NULL AND d.IDCard IS NOT NULLi.IDCard IS NOT NULL AND d.IDCard IS NULL
更稳妥的做法是用 ISNULL(i.IDCard, '>') != ISNULL(d.IDCard, '>')，前提是字段值本身不会出现 > 这种字符串；或者统一转成 HASHBYTES('SHA2_256', ISNULL(i.IDCard, '')) 再比对——后者适合大字段，避免字符串比较性能抖动。
真正难的不是写触发器，而是想清楚：你要的日志是用来追责、合规检查，还是调试数据漂移？前者要防篡改（日志表加只读权限、定期导出），后者要易查询（字段全用 TEXT 存，别截断 JSON）。选错方案，后面补救成本远高于一开始多花半小时设计表结构。
