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

　　去年七月份那版审计系统，我原以为存储过程+触发器就是银弹，结果上线第二天就被运营追着骂——他们查某张表的变更记录，发现凌晨三点有二十条INSERT没触发审计日志。我盯着监控看，触发器明明写着AFTER INSERT，存储过程也调了sp_executesql，可日志表就是空的。后来发现是触发器里嵌套的存储过程报了个隐式转换错误，SQL Server直接吞了异常，连个黄标都没亮。

　　隔壁测试小哥叼着冰棍凑过来，显示器上贴的便签卷了边，写着“别碰触发器”。他指着我的代码说：“你触发器里写TRY-CATCH了吗？”我一拍桌子——还真没写。当时觉得触发器就几行代码，出问题直接回滚事务就行，结果SQL Server的触发器里异常处理和存储过程完全两码事，不显式捕获的话，整个触发器直接静默失败。后来加了RAISERROR，日志表终于有记录了，但运营又反馈“查询慢”——原来每条变更都要调存储过程写日志，高并发时触发器成了瓶颈。

　　工位旁的加湿器一直在冒白雾，我盯着测试机屏幕上的充电线缠成一团，突然想起之前看过的一篇论文，说触发器是“隐式执行”，和显式调存储过程的行为模式不一样。比如，批量INSERT时，触发器会为每条记录单独触发，而不是像存储过程那样可以优化成批量操作。我改了代码，把触发器里的日志逻辑移到应用层，用存储过程封装变更和审计，结果测试机突然蓝屏——原来是存储过程里用了临时表，并发时表名冲突了。

　　那天晚上十点，运营总监在群里@我：“审计日志缺了半小时的数据，财务要查账！”我翻日志表，发现那段时间触发器没执行，但存储过程明明调了。后来查SQL Server的默认跟踪，发现是触发器所在的数据库触发了自动增长，而文件组设置有问题，增长时阻塞了所有DML操作——触发器在等待锁，存储过程却因为事务隔离级别不同，直接超时回滚了。我蹲在工位下修文件组配置，外卖凉了都没注意，抬头看见测试小哥在玩《原神》，问他：“你之前说触发器坑多，具体指哪些？”他头也不抬：“触发器会绕过约束检查，比如你有个CHECK(age>18)，触发器里改age=10，SQL Server不会报错，但数据就脏了。”

　　我原以为存储过程+触发器能解决所有审计问题，结果发现这俩玩意儿根本不是“组合技”，而是“叠buff”——触发器的隐式行为、存储过程的显式控制，混在一起反而更难排查。比如，我们有个表有AFTER UPDATE触发器，里面调了存储过程A，存储过程A又调了存储过程B，B里有个动态SQL拼错了表名，结果触发器报错，但错误信息被层层包裹，最后在日志里只看到“存储过程执行失败”，根本找不到具体哪行代码出问题。测试小哥说：“这就是为什么我建议审计逻辑全放应用层——至少错误堆栈是完整的。”

　　可老板不同意，他说：“应用层审计容易被绕过，比如直接调存储过程不走API。”我反驳：“但触发器+存储过程的问题更多，比如我们上周那个案例，审计日志表和业务表在同一数据库，业务表做大表分区时，审计日志也被分走了，财务查历史数据时，发现部分日志“消失”了——其实是分区策略没同步。”老板沉默两秒，说：“那你们能不能把审计日志表放到单独的数据库？”我点头，心里却想：这又得改触发器里的连接字符串，搞不好又出新的兼容性问题。

文章配图，仅供参考

　　后来我们做了个折中方案：业务表的变更走触发器，但触发器只做轻量级标记（比如插一条“待审计”记录到中间表），真正的审计逻辑由定时任务调存储过程处理。这样既利用了触发器的实时性，又避免了触发器里的复杂逻辑。测试小哥说：“这就是‘优胜劣汰’——触发器适合简单场景，存储过程适合复杂逻辑，硬凑在一起只会更糟。”我点头，想起上周那个数值崩盘的复盘——当时我们为了“提升玩家留存”，在卡池里加了保底，结果触发器没监控到保底计数器的异常重置，导致部分玩家实际掉率比预期低20%。运营发现时，已经过了三个版本，补偿方案都难做。

　　现在我们的审计系统还在迭代，但我已经不敢说“完美”了——上周刚发现，存储过程里用了MERGE语句，在SQL Server 2016上有个已知bug，会导致部分变更不触发审计。测试小哥说：“这就是数据型业务的坑——你以为搞定了技术，结果业务规则一变，所有技术方案都得重来。”我盯着屏幕上的充电线，突然觉得，或许真正的“高可用”，不是靠某个技术组合，而是靠“能快速发现并修复问题”的能力——就像我们现在的审计系统，虽然偶尔还是会漏记录，但至少能在半小时内定位到问题，比之前“查三天找不到原因”强多了。

　　对了，昨天运营又提了个需求：要审计玩家充值时的IP地址变化。我看了看现有的触发器+存储过程架构，默默打开应用层的代码——这次，或许该试试另一种方案了。

（编辑：均轻资讯网）

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