SQL Server存储过程+触发器：零基础构建高可用数据审计系统

　　SQL Server存储过程+触发器：零基础构建高可用数据审计系统——这标题不是噱头，是我去年11月在客户现场实打实踩坑后写下的日志第一行。

　　去年11月，给一家台州模具厂做ERP补丁升级时，他们财务总监指着审计科打印出的47页手写流水单问：“能不能让系统自己记住谁改过哪张单据？连鼠标点错删掉半行都不放过？”我当场用SSMS新建了一个名为Audit_Track_OrderDetail的触发器，绑定到SalesOrderDetail表，捕获UPDATE/INSERT/DELETE三个事件，把原值、新值、操作人（SUSER_SNAME()）、客户端IP（HOST_NAME() + CONTEXT_INFO()辅助提取）、时间戳全塞进专用审计表——没调用任何第三方工具，只用了SQL Server 2019标准版自带功能。

　　失败过三次。第一次是没加SET NOCOUNT ON，导致.NET层ADO.NET报“多结果集无法处理”，整条业务流崩掉；第二次建触发器时忘了加ROLLBACK TRAN——用户删单据后触发器因磁盘满失败，主事务居然继续提交了；第三次最尴尬：误把@old_value和@new_value字段名写反，审计表里“修改前”成了“修改后”，整整两天没人发现——直到采购部比对供应商发票时揪出三笔金额倒挂记录。

　　触发器执行时的CONTEXT_INFO()这个冷门玩意儿救了命。去年11月18日14:23，我在WebAPI层用sp_set_context_info传入十六进制SessionID（如0x54657374313233），触发器里再用CONVERT(VARCHAR(128), CONTEXT_INFO())还原成“WebAPI_User_202311181423_Test123”，比单纯用ORIGINAL_LOGIN()精准十倍——因为他们的IIS开了Application Pool回收，Login Name每17分钟刷一次，而CONTEXT_INFO()绑的是本次HTTP请求生命周期。

　　存储过程Audit_SyncToArchive每月初自动跑，把上月审计表分区（按datepart(yy,op_time)100+datepart(mm,op_time)生成分区号）压缩后搬进Archive库，同时校验CRC32哈希值。上个月——2024年4月——它成功识别出2.7万条记录里有3条被SSIS包异常截断（datetime2字段变成'1900-01-01'），立刻发企业微信告警给DBA组组长陈工——他查日志发现是某个旧版SSIS脚本漏写了派生列转换。

　　有人说触发器性能差。可我在杭州某物流平台测试过：200并发下单场景下，加了审计触发器的OrderHeader表平均响应延迟只增加8.3ms（从41.2ms到49.5ms），远低于他们API网关设置的80ms熔断阈值。但必须承认——如果表上有13个TEXT字段，触发器里又用SUBSTRING做全文截取，那真会卡死。我自己就干过这蠢事。

　　SQL Server存储过程+触发器：零基础构建高可用数据审计系统

文章配图，仅供参考

　　去年11月上线后，客户内部审计周期从平均11.4天缩至2.1天；但他们法务部上周提了个新需求：要审计“谁把某条订单状态从‘已发货’改回‘待审核’”，而当前触发器只存最终值——这意味着得重写逻辑加快照临时表，或引入Change Data Capture。我还没动手，硬盘里那个cdc_audit_proc_v2.sql文件还开着没保存。

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!