不少程序员在开发项目时都和触发器打过交道，可如今，关于触发器优缺点以及该不该废除的讨论越来越多。今天咱就好好唠唠这个事儿，因为在面试中也是被经常问到。

一、曾经的得力助手

早些年，触发器在数据库编程里那可是常客，跟存储过程一样，几乎每次项目迭代都能看到它的身影。为啥呢？那时候技术条件有限，就拿我刚入行时参与的运营商流量包兑换业务来说。当时市面上没什么好用的开源分布式锁，小团队又没能力自研，要是只靠普通的业务逻辑扣减流量包数量，根本拦不住并发抢包时可能出现的超卖问题，这在当时可太常见了。

咋办呢？大家想到了在数据库层用触发器来兜底。具体咋做的呢？其实就是在流量包兑换前加一道“关卡”，用前置触发器检查库存。要是库存没了，触发器就直接抛出异常，终止操作。这就好比在商店门口安排了个保安，没货了就不让人进去抢，确实解决了不少实际问题。

二、如今暴露的问题

但随着时间推移，触发器的问题逐渐暴露出来。现在不少小伙伴喜欢把业务逻辑一股脑儿写进触发器里。就拿统计商品浏览量来说，有人觉得在添加浏览记录后，让触发器直接给浏览量加一挺方便。但这看似简单的操作，其实隐藏着不少问题。

这种锦上添花的功能，真没必要占用数据库宝贵的实时处理资源。像统计浏览量这类不太紧急的任务，完全可以用异步处理或者消息队列的方式来搞定。数据库的实时处理能力是有限的，触发器这么一折腾，整体性能肯定受影响。

另外，触发器和存储过程一样，脚本都写在数据库里，这给后续维护带来了大麻烦。别人看这些脚本，理解起来费劲，排查错误更是难上加难。要是处理不好，还特别容易出现数据不一致的情况，到时候数据乱了套，项目可就遭殃了。

三、总结：该舍弃就舍弃

综合来看，虽然触发器曾经立下过汗马功劳，但如今它带来的弊端远远超过了价值。在开发项目时，咱得从整体性能、维护难度等多方面去考虑，不能只念着它过去的好。该舍弃就舍弃，寻找更合适的技术方案来解决问题，这样才能让项目更稳定、高效地运行。

要是你在开发中也遇到了和触发器有关的问题，或者对这篇文章有啥看法，欢迎在评论区留言讨论，大家一起交流进步！