SQL Server触发器通过ORIGINAL_LOGIN()获取真实操作者，结合CONTEXT_INFO()补充应用层标识；审计表须含audit_id、table_name、operation_type、host_name、app_name、login_name、change_time及old/new_values字段；UPDATE时需比对INSERTED/DELETED值而非仅依赖COLUMNS_UPDATED()。
触发器怎么捕获“谁在改数据”
SQL Server 2016 的触发器本身不直接暴露操作者身份，SYSTEM_USER 和 ORIGINAL_LOGIN() 是关键入口。前者返回当前会话的登录名（可能被应用层伪造），后者返回连接建立时的真实登录名，更可靠。但要注意：如果应用用统一账号（比如 app_user）连库，所有触发器记录下来的都是这个账号，无法区分具体接口或人——这时候得靠应用层在 CONTEXT_INFO 或自定义字段里传标识，触发器再从 CONTEXT_INFO() 里读。
审计日志表结构必须包含哪些字段
只记 INSERTED 和 DELETED 行内容远远不够。真实排查时你最常问的是：“这行是谁、什么时候、从哪台机器、用什么语句改的？” 所以至少要存：
-
audit_id（自增主键，便于排序和分页） -
table_name（触发器所在表名，用OBJECT_NAME(@@PROCID)不靠谱，应硬编码或从EVENTDATA()提取） -
operation_type（'INSERT'/'UPDATE'/'DELETE'） -
host_name（HOST_NAME()，客户端机器名，可被伪造但有参考价值） -
app_name（APP_NAME()，WinCC、SSMS、.NET SqlClient 各有不同字符串，能区分工具类型） -
login_name（ORIGINAL_LOGIN()，比SYSTEM_USER更防冒用） -
change_time（GETDATE()，不用SYSDATETIMEOFFSET()，避免时区转换干扰） -
old_values和new_values（NVARCHAR(MAX)类型，用FOR JSON AUTO或拼接字符串存变更前后快照）
UPDATE 触发器里怎么安全获取变更字段
别信 COLUMNS_UPDATED() 返回的位图——它只告诉你哪些列“可能被更新”，不保证值真变了。比如 UPDATE t SET name = name，位图也会标中 name 列，但实际没变。真正要定位脏数据来源，得比对 INSERTED 和 DELETED 中对应字段值是否相等。示例逻辑：
IF UPDATE(status) AND (SELECT status FROM INSERTED) != (SELECT status FROM DELETED)
注意三点：
- 字段为
NULL时不能用!=，得写(SELECT status FROM INSERTED) IS NULL AND (SELECT status FROM DELETED) IS NOT NULL这类组合判断 - 大字段（
TEXT、XML、VARBINARY）慎用直接比较，容易超内存或拖慢触发器；可先用CHECKSUM()粗筛，再对 checksum 相同的做精细比对 - 不要在触发器里调用远程服务或写文件，否则事务阻塞风险极高；审计日志表必须和业务表在同一数据库、同一事务内写入
为什么触发器日志查不到某些修改
常见漏网之鱼有三类：
- BULK INSERT、
BCP、SqlBulkCopy默认绕过触发器（除非显式加FIRE_TRIGGERS选项） - 启用了
TRUSTWORTHY数据库且使用了EXECUTE AS的存储过程，可能让ORIGINAL_LOGIN()变成执行者而非调用者 - DBA 手动执行
DISABLE TRIGGER ... ON ...后忘了恢复，这种操作不会留痕——所以建议把触发器状态纳入日常巡检脚本，定期查sys.triggers的is_disabled字段
最隐蔽的坑是：触发器里写的审计日志表如果加了外键或约束，而业务事务又没提交，会导致死锁或阻塞。审计表务必保持“零约束、零索引（除主键外）、堆表优先”，写入后再用作业异步建索引归档。
