SQL Server存储过程与触发器实战：构建高可用数据审计系统

去年七月，我接手过一个金融系统的数据审计项目——客户要求对所有涉及资金变动的操作实现毫秒级追踪，且审计日志必须与业务数据强一致。传统方案要么用应用层埋点（容易漏记录），要么靠ETL抽数据（延迟高），最后我们选了SQL Server的存储过程+触发器组合——别笑，这招在特定场景下比某些分布式追踪系统还稳。

存储过程负责封装审计逻辑，触发器负责实时捕获变更——这组合的第一个优势是"零侵入"。比如用户表UserInfo的UPDATE操作，我们直接在触发器里写：INSERT INTO AuditLog(TableName,OperationType,OldData,NewData,CreateTime) SELECT 'UserInfo','UPDATE',d.,i.,GETDATE() FROM deleted d JOIN inserted i ON d.ID=i.ID。看明白没？deleted和inserted是SQL Server触发器特有的虚拟表，自动记录变更前后的数据，连JOIN条件都不用应用层传。

文章配图，仅供参考

存储过程的另一个黑科技是"动态SQL审计"。比如有个客户要求审计所有包含"SELECT FROM User"的查询（防止敏感数据泄露），我们用存储过程动态解析SQL文本：DECLARE @sql NVARCHAR(MAX)=N'SELECT FROM sys.dm_exec_sql_text(sql_handle)'; EXEC sp_executesql @sql——通过解析执行计划里的sql_handle，连动态SQL都能抓到，这比某些APM工具的SQL解析还准。

高可用怎么保证？我们用了SQL Server的Always On可用性组，把审计库和业务库放在同一个可用性组里。去年双十一峰值期间，主库宕机切换时，审计日志一条没丢——因为触发器是在事务提交前写日志的，只要业务数据提交成功，审计日志必然同步到备库。这点比某些异步写消息队列的方案可靠多了。

但必须承认，这方案也有局限——比如触发器会增加10%-15%的响应延迟，对超高频交易系统不友好。上个月有个量化交易团队找过来，我们直接劝退改用Change Data Capture（CDC）——不过话说回来，CDC在SQL Server企业版才支持，标准版还是得靠触发器+存储过程这套"土办法"。

下一步打算试试把审计日志用Temporal Table（时态表）存储——SQL Server 2016+的版本支持，直接通过SYSTEM_TIME查询历史数据，连触发器都不用写了。不过老系统升级得谨慎——去年给某银行升级时，发现Temporal Table的索引策略和传统表完全不同，查询计划走了全表扫描，性能直接崩了50%...这事儿得慢慢调。

（编辑：站长网）

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