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

文章配图，仅供参考

　　那天下午，测试环境的机器风扇嗡嗡转，我在那写第一个触发器。你知道触发器最坑的地方是啥吗？不是逻辑复杂，是它「偷偷执行」的特性——你写的时候觉得挺简单，一上线，主库突然变慢，DBA冲过来问「谁在搞事情」，你才发现触发器里有个死循环，或者嵌套了八层查询。我原以为加个`IF @@ROWCOUNT=0 RETURN`就能防住空操作，结果发现有些修改是批量提交的，`@@ROWCOUNT`根本不准，最后还得在触发器里加事务控制，搞得代码跟蜘蛛网似的。

　　存储过程那边更搞笑。我们为了「高可用」，把核心审计逻辑全塞存储过程里，想着这样能减少网络传输，结果测试的时候发现，存储过程里调用的另一个存储过程，参数类型没对齐——一个传的是`VARCHAR(50)`，另一个接的是`NVARCHAR(100)`，直接报错。更绝的是，有个存储过程里用了`TRY...CATCH`，但没处理`ERROR_MESSAGE()`，错误日志里就一行「执行失败」，连具体原因都没有。我蹲在工位上改代码，群里一直在@我，说「审计页面加载超时」，抬头一看，饮水机那边在换桶，水溅了一地，手写的排期表被泡得字都糊了。

　　但你说这俩东西没用吗？还真不是。我们后来搞了个「优胜劣汰」的机制——触发器负责实时捕获基础变更（比如`INSERT`/`UPDATE`/`DELETE`），存储过程负责复杂逻辑（比如合并多条变更、生成审计摘要）。触发器的优势是「无感知」，数据一变它就跑，缺点是「不可控」——你没办法在触发器里调外部API，也没法做异步处理；存储过程反过来，能写复杂逻辑，但得显式调用，性能开销也大。我们最后是把触发器当「哨兵」，存储过程当「处理器」，哨兵发现异常就记日志，处理器定期处理日志，生成最终审计报告。

　　手机这时候震动，电量掉到15%，我插上充电器，继续吐槽。最扯的是那次压测——我们模拟了100个并发修改，触发器那边直接崩了，报错是「触发器嵌套层级超过32」。我查了半天才发现，有个触发器A调用了存储过程B，存储过程B又触发了触发器C，C又调了D...最后形成了个死循环。而存储过程那边，压测时主库CPU直接飚到90%，因为有个存储过程里用了`CURSOR`，逐行处理数据，效率低得离谱。后来我们把`CURSOR`全换成`JOIN`，性能才稳下来。

　　说到这，我想起上个月那个砸了的活动——我们推了个新功能，结果审计系统没捕获到部分字段的变更，用户投诉说「数据被篡改」，我们查了半天才发现，是触发器里漏写了一个字段。那会儿会议室一直被占着，我在走廊里改代码，测试妹子举着手机说「用户又在催了」，我头都没抬，说「再给我十分钟」。结果十分钟后，代码是改好了，但部署的时候发现存储过程依赖的视图没刷新，又得回滚，整个活动页延迟了半小时上线，ROI直接掉了一半。

　　但你说这系统现在稳了吗？也不尽然。上周我们新增了个审计规则，要在存储过程里加个条件判断，结果改完测试环境没问题，上线后主库突然变慢。DBA查了半天，说是因为存储过程里的`WHERE`条件没走索引，全表扫描了。我原以为`EXPLAIN`计划在存储过程里也能用，结果发现SQL Server的存储过程优化是「延迟编译」的，参数不同，执行计划可能完全不一样。最后我们不得不加了`OPTION (RECOMPILE)`，才把性能拉回来。

　　现在回头看，这系统能跑起来，真不是靠哪个技术「绝对厉害」，而是靠「组合」。触发器负责实时，存储过程负责复杂，日志表负责持久化，三者互补。就像我们组那个老开发说的：「没有银弹，只有组合拳。」我原以为他能说出什么高深理论，结果他补了句：「就像你搞对象，光长得帅不行，还得会哄人，光会哄人也不行，还得有钱。」全组笑喷，测试妹子说「这比喻太直男了」，他回「直男才实在」。

　　现在这系统还在跑，偶尔出点小问题，但大体稳了。我最近在琢磨，要不要把部分存储过程换成CLR集成，用C#写逻辑，这样能调用外部API，也能做异步处理。但产品说「别折腾了，现在够用了」，我转头跟设计说「你看这界面能优化下不」，设计说「排期满了，下季度再说」。我叹了口气，继续盯后台数据——每分钟自动刷新一次，数字跳得挺欢，就像这系统，偶尔卡顿，但总算没停。

（编辑：草根网）

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