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

　　SQL Server存储过程与触发器实战：构建高可用数据审计系统——这标题不是我拍脑袋想的，是去年九月在华北某三甲医院HIS系统升级现场，被DBA老张甩到我桌上的需求文档原题。当时他们刚上线SQL Server 2019标准版，audit表日均写入127万条记录，但触发器延迟峰值飙到8.3秒，门诊挂号页面直接卡死。我盯着那个红色ERRORLOG——"Cannot insert duplicate key in object 'dbo.AuditLog'”，心里发毛：原来他们没设复合唯一约束，只建了单字段主键。

　　我们删掉原触发器里那句SET NOCOUNT OFF——没人告诉他们这会把每条INSERT都塞进网络包头；改用EXEC sp_executesql传参，把@LoginName和@HostName拼进动态SQL前先用REPLACE(@LoginName, '''', '''''')做二次转义；最关键的，把原来的AFTER INSERT改成INSTEAD OF INSERT，把审计字段填充逻辑提到业务插入之前，在事务内原子处理——结果审计延迟压到92ms以内，P95稳定在114ms。对，就是114ms，我拿PerfMon录了整整三天，导出Excel画折线图，横轴是时间戳，纵轴是Duration_ms，小数点后一位都不敢四舍五入。

文章配图，仅供参考

　　失败过两次。

　　第一次是在测试环境模拟并发——12个JMeter线程同时UPDATE患者主索引表，触发器调用存储过程sp_InsertAuditRecord，但该过程里用了WAITFOR DELAY '00:00:00.5'做人工阻塞调试（别笑，真有人这么干），导致事务锁住sys.dm_tran_locks里63个资源，死锁图里出现KEY: 7:72057594044977152 (ac1a2b3c...)，连带医保结算模块挂了47分钟。第二次更绝：开发人员偷偷把审计触发器里的INSERT语句替换成表变量+MERGE，说“性能更好”——结果第二天凌晨2:13分，tempdb的版本存储区暴涨至42GB，log_reuse_wait_desc变成VERSION_GENERATION_QUEUE，备份作业全堵在队列里动不了。监控告警邮件堆到73封才被值班同事发现。

　　我的实测数据："SQL Server存储过程与触发器实战：构建高可用数据审计系统"——这个标题本身就在冒汗。它优点在"新技术"？不全是。SQL Server 2016开始支持SCHEMABINDING + EXECUTE AS OWNER的组合，能绕过跨数据库权限校验，我们用在审计库与业务库分离场景；SQL Server 2022的T-SQL函数STRING_SPLIT()带排序保证（ORDER BY ordinal），终于不用手写递归CTE拆分多值字段变更日志；但最要命的是——没人告诉你SQLCLR触发器在Always On可用性组里，默认不启用EXTERNAL_ACCESS权限，去年九月我们在西城区政务云部署时，触发器报错Msg 6522，折腾了6小时才查到是AG副本未同步master数据库里的asymmetric key……这种细节，微软文档藏在一页PDF的脚注第三行。

　　我主观判断：这套方案在中小规模OLTP系统里能跑通，但别碰金融级实时清算——审计逻辑一旦混进核心交易链路，哪怕只加37ms额外开销，高频场景下就是雪崩起点。上周客户问我能不能把触发器改成Service Broker异步发消息，我说试过，但Service Broker队列在节点故障切换时可能丢最后3条消息，他们立刻摆手：“审计日志不能丢，一条都不能少。”

　　现在我正在重写sp_GetChangeDetails这个存储过程，打算引入memory-optimized table变量替代临时表，但还没敢上生产——因为测试发现SQL Server 2019 CU18对nvarchar(max)字段在内存表变量里有隐式截断Bug，官方KB5005223补丁只修了SELECT，没修INSERT…所以，你猜接下来我得找谁？

（编辑：均轻资讯网）

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