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 中对应字段值是否相等。示例逻辑：

MimicPC

MimicPC是一款通过云端运行 Stable Diffusion、ComfyUI、Flux 等 AI 应用的创作平台。

下载

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 字段

最隐蔽的坑是：触发器里写的审计日志表如果加了外键或约束，而业务事务又没提交，会导致死锁或阻塞。审计表务必保持“零约束、零索引（除主键外）、堆表优先”，写入后再用作业异步建索引归档。