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

　　去年1月那项目，存储过程和触发器搭的审计系统，上线第三天就被运维骂娘——我原以为触发器写死表结构能省事，结果业务方临时改了三个字段，整个触发器链直接崩了。那天下雨，机房冷风机嗡嗡响，我蹲在工位上改代码，显示器右下角的时间跳到18:47，外卖凉透了都没顾上吃。

文章配图，仅供参考

　　触发器才是真正的坑货。我原以为“AFTER INSERT”能抓所有新增数据，结果业务方用了批量插入，触发器只执行了一次，审计日志里少了一半记录。更绝的是，有个触发器里写了“UPDATE 主表 SET 状态=1”，结果主表有外键约束，直接锁了半小时表，整个系统卡在87%的构建进度上不动弹。那天下午，测试小妹在隔壁工位接了个电话，声音大得能穿透玻璃：“什么？又宕机了？不是刚修好吗！”我抬头看了眼她的屏幕，测试用例列表一片红，跟她脸上的表情一模一样。

　　但你说这套东西没用？也不至于。优胜劣汰的道理在这行太明显了——存储过程再难维护，也比把审计逻辑散在应用层强。去年双十一前，我们用存储过程重构了订单审计，把原本分散在Java、Python、Shell里的逻辑全塞进过程里，结果系统负载降了30%。运维总监拍着我肩膀说“这波血赚”，我盯着他油光锃亮的脑门想：要是早知道会这样，当初就不该跟架构师吵那三小时架。

　　那架吵得挺绝。架构师坚持用消息队列做审计，我说“消息队列丢消息的概率比触发器报错高十倍”，他拍桌子说“触发器是反模式”。结果呢？他搞的消息队列审计，双十一当天丢了200多条日志，运维查监控查到凌晨三点；我的触发器审计，除了那次批量插入的坑，全程稳如老狗。现在他见着我都绕着走——不过听说他最近在学存储过程，我挺期待看他怎么写动态SQL。

　　说回技术细节。存储过程里最容易踩的坑是“隐式事务”——我见过有人把整个过程包在一个BEGIN TRAN里，结果中间某条SQL报错，整个事务回滚，审计日志全没了。触发器里更绝的是“递归触发”，比如A表触发器更新B表，B表触发器又更新A表，直接死循环。我们当时为了防这个，在触发器开头加了“IF @@NESTLEVEL > 1 RETURN”，结果测试时发现，有些合法操作也会触发递归，最后不得不把阈值调到3——这个数值我说不准对不对，但至少没再报过死循环的错。

　　同事老李有个习惯：写存储过程必加“PRINT”语句，方便调试。有次他写完一个复杂的审计过程，运行时报错，查了半天发现是某个PRINT语句里的字符串没引号。那天他盯着屏幕看了十分钟，突然转头问我：“你说，是不是所有bug都藏在最显眼的地方？”我没理他，继续改我的触发器——他工位上的绿萝快死了，叶子耷拉着，跟他现在的表情一模一样。

　　同行生态里，用存储过程和触发器的越来越少了。上次参加技术沙龙，聊到审计系统，十个里有八个说“用日志框架+ES”，剩下两个里，一个用AOP，另一个...就是我这种老古董。但我觉得吧，技术选型就跟穿衣服似的——别人都穿潮牌，你穿个中山装，不一定丑，但得有底气。我敢用存储过程，是因为我清楚它的边界：复杂业务逻辑？滚；简单审计需求？真香。

　　现在这系统跑了快一年，除了那次批量插入的坑，没出过大问题。运维说“比消息队列靠谱”，产品说“审计日志全了”，连测试小妹都夸“报错信息比以前清楚”。但我知道，这玩意的维护成本不低——上次业务方要加个字段，我改了三个存储过程、两个触发器，花了半天时间。要是用日志框架，可能十分钟就搞定了。可你说换？我舍不得——这系统就像我养的孩子，虽然调皮，但至少听我的话。

　　最近在考虑重构，把部分存储过程换成动态SQL，触发器改成应用层拦截。但一想到要改那么多代码，又有点怂——毕竟，谁愿意动自己写的“稳定”系统呢？说不定哪天，我会像那个架构师一样，真香也说不定。不过眼下，我还是先把手头的触发器优化完吧——显示器右下角的时间又跳了，19:23，该点外卖了。

（编辑：站长网）

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