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

　　去年一月份那会儿，我原以为给审计系统加存储过程和触发器就是写两段代码的事儿，结果那周连着三天凌晨三点半被告警轰醒，开发还追着骂“你们这破触发器卡死主库了”。后来复盘的时候才发现，存储过程里嵌套了七层游标，触发器里还调了外部API——这他妈能不出事儿？可你说不用这些吧，审计日志又没法实时同步，最后还是咬着牙重构了四遍，现在才算勉强稳住。

文章配图，仅供参考

　　其实这事儿怪我自己。当初设计的时候图省事儿，觉得用触发器抓变更最直接，存储过程里写点逻辑就能把数据灌到审计表。结果开发为了“灵活”，在触发器里塞了各种条件判断，有个表更新时居然要遍历全表做校验——我原以为`INSTEAD OF`触发器能绕过主操作，结果发现它根本没触发，因为原SQL里用了`NOLOCK`。那晚我蹲在机房地上改代码，开发在旁边阴阳怪气：“你们运维不是最懂性能吗？这触发器写得跟屎一样。”我盯着他电脑上的VS Code，界面上还开着个未保存的React项目，心想你丫写前端的有脸说我？

　　第二天更离谱。重构后的存储过程用`OPENJSON`解析变更数据，测试环境跑得飞快，上线后主库突然开始丢连接。查日志发现是`sp_who2`里全是`SLEEPING`进程，每个都卡在`WAITFOR DELAY '00:00:00.1'`——开发在存储过程里加了延迟，说是为了“避免并发冲突”。我直接炸了：“你当这是前端防抖啊？SQL Server的锁机制是摆设吗？”他挠挠头：“那怎么办？不加延迟的话，触发器里的邮件有时候发不出去。”我盯着他电脑上的Outlook，收件箱里堆着三百多封未读邮件，其中一半是测试环境的触发器报错——这货居然连错误处理都没写！

　　第三次重构的时候，我彻底放弃了触发器。改用变更数据捕获（CDC）配合服务代理（Service Broker），存储过程只做数据转换，审计日志异步写入。开发又跳出来反对：“CDC要开额外跟踪，影响性能！”我直接把监控截图甩他脸上：“你看看现在主库的CPU，比用触发器的时候低了40%。”他没话说了，但转身就在Jira上提了个“优化CDC延迟”的票——那票到现在还挂着，状态是“待排期”。

　　其实最让我后怕的是备份。那天重构完，我忘了对审计库做完整备份，只做了差异备份。结果第二天开发误删了张审计表，恢复的时候发现差异备份里没有表结构——因为表是重构后新建的，而完整备份是重构前的。我盯着恢复失败的提示，后背直冒冷汗。最后是找了个离线副本手动拼数据，花了整整六个小时。开发在旁边吃外卖，汤汁滴在键盘上：“你们运维不是应该自动备份吗？”我盯着他碗里的红烧肉，心想你丫要是少改点代码，我能这么被动？

　　现在这套系统算是稳了，但我知道它活不过两年。开发还在提各种“灵活需求”，比如要在审计日志里加用户IP、设备信息，甚至要记录操作时的浏览器版本——我直接拒绝：“这些字段得改表结构，触发器又得重写。”他撇撇嘴：“那你们运维得学学NoSQL，文档型存储多方便。”我盯着他电脑上的MongoDB文档，心想你丫连SQL的`JOIN`都写不利索，还跟我谈NoSQL？

　　其实说到底，这系统能活下来，靠的就是“优胜劣汰”。触发器太慢？换CDC；存储过程太复杂？拆成小函数；备份不可靠？加离线副本。运维这行就这样，没有一劳永逸的方案，只有不断打补丁的妥协。就像那晚在机房，我改完代码抬头，发现窗外天快亮了，屏幕上还开着三个代码窗口、两个监控面板，以及一个未保存的Word文档——里面记着开发提的所有“灵活需求”，我一条都没标“已完成”。

　　下一步打算把审计日志同步到ES，至少查询能快点。但开发又提了新需求：要在日志里加操作时的地理位置信息。我盯着他手机上的GPS定位，心想你丫要是能先保证代码不报错，我就谢天谢地了。这事儿本来能避免的，如果当初不图省事儿用触发器，如果开发不乱改代码，如果备份能自动跑……可运维哪有如果？只有凌晨三点半的告警，和永远改不完的代码。

（编辑：站长网）

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