站长学院：SQL Server存储过程与触发器实战

　　去年秋天给站长学院做SQL Server培训，我原以为存储过程和触发器这种老古董没人听，结果会议室挤得连外卖小哥都找不到地方放奶茶——三十多号人，一半是运维，一半是开发，还有个戴渔夫帽的站长边记笔记边敲键盘，屏幕上是他刚搭的电商后台。培训到一半突然下雨，空调滴水声混着键盘声，我讲到触发器递归陷阱时，前排有个穿格子衫的哥们突然举手：“老师，我上周刚被这玩意儿坑到凌晨三点。”

　　他说的是个订单系统，老板要求“付款后自动更新库存，同时给供应商发邮件，再给客户发短信”。开发图省事，直接在付款表的AFTER INSERT触发器里塞了三个存储过程——更新库存、调邮件API、调短信API。结果测试时发现，偶尔会漏发短信，偶尔会重复发，最离谱的是有次库存更新后数值不对，查日志发现触发器里的存储过程被调了两次。“我原以为是事务没控制好，结果抓包发现是触发器递归了——付款表触发器更新了库存表，库存表的AFTER UPDATE触发器又反推回来改了付款表，SQL Server默认允许递归，这一来二去，整个流程跟喝多了似的乱转。”

文章配图，仅供参考

　　我听着乐，这类坑我早见过——触发器最邪门的地方就是“隐式执行”，你以为它只是个附加逻辑，结果它可能偷偷改数据、偷偷锁表、甚至偷偷递归。去年给某银行做系统迁移，旧系统的触发器里嵌了三层存储过程，新环境一跑，直接把索引干碎了，DBA查了一周才找出是触发器里的某个动态SQL没加NOLOCK提示。

　　但话说回来，存储过程和触发器能活到现在，肯定有点东西。比如上周有个站长问我：“老师，我们有个老系统，每天要处理三百多万条订单数据，用存储过程批量更新比用ORM快三倍，这算不算优胜劣汰？”我点头——存储过程的优势就是“近水楼台”，它直接跑在数据库引擎里，不用像应用层那样传数据、等响应、处理异常，尤其是复杂计算或批量操作，效率确实高。触发器也一样，数据变更时自动触发，比应用层写监听逻辑可靠多了——你总不能指望每个开发都记得在所有更新操作后手动调用监控函数吧？

　　不过最让我意外的是培训后的反馈。有个站长私聊我说：“我们以前觉得存储过程和触发器是‘落后技术’，现在才发现，有些场景真离不开它们。”他举了个例子：他们做物流系统，要实时计算包裹的预计到达时间，涉及天气、路况、仓库库存等十几个变量，用存储过程把所有逻辑封装在数据库里，比用微服务拆成八个小模块靠谱多了——“至少不会因为某个服务宕机，导致整个计算链断掉。”

　　但我也得泼冷水——这些“优胜”的场景，往往有个共同点：数据强关联、逻辑集中、对性能敏感。一旦场景变复杂，比如需要分布式处理、需要动态扩展、需要多系统协作，存储过程和触发器就成了“定时炸弹”。去年双十一，某电商的触发器因为并发量太高，直接把数据库连接池撑爆了，整个订单系统瘫痪了两小时——后来他们把触发器里的逻辑拆出来，用消息队列+微服务重构，才扛住流量。

　　说到底，技术没有绝对的好坏，只有适不适合。就像培训时那个戴渔夫帽的站长，他后来跟我说：“我们现在用触发器只做两件事：数据审计和简单关联更新，复杂的业务逻辑全丢到应用层。”我问他怎么界定“简单”，他笑：“能在一页SQL里写完的，算简单；超过三页的，赶紧跑。”

　　培训结束时，雨停了，阳光透过窗户照在白板上，我擦掉最后一块板书，转头看见那个穿格子衫的哥们还在敲键盘——他在改触发器代码，屏幕上是新加的递归检查逻辑。金丝眼镜站长凑过去看，两人嘀咕了几句，突然同时抬头：“老师，下次讲讲怎么用存储过程调外部API呗？我们最近想把这个触发器里的邮件功能改成异步的。”

　　我点头，心里却想：这帮人，刚被触发器坑完，又惦记着玩更花的——不过也好，技术不就是这样吗？踩坑、填坑、再踩更大的坑，最后活下来的，都是能在这堆坑里找出最优解的。

　　至于我？下回培训得加一节“触发器防坑指南”，再备点润喉糖——讲存储过程和触发器，比讲分布式架构费嗓子多了。

（编辑：站长网）

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