before update触发器多语句与多独立触发器选型对比

优先选方案a：用单个BEFORE UPDATE触发器整合全部3项校验逻辑，这是生产环境用触发器落地业务约束的通用最佳实践，核心理由如下：

• 执行开销可控：同一条UPDATE语句触发时，单个触发器只会初始化一次执行上下文，没有多个触发器来回切换的额外损耗。你可以把执行速度快、拦截失败概率高的校验放在最前面，一旦命中错误规则直接抛错终止，后面的重查询根本不用执行，能省很多无效的数据库资源。要是拆成3个独立触发器，绝大多数数据库对同一触发时机的触发器默认没有严格的执行顺序保证，就算部分库支持手动设置顺序，后续维护时有人重建触发器、改了配置，很容易把要跑大表关联的重查询挪到最前面，明明第一个简单校验就能拦下的错误，非要先跑一遍慢查询，平白给数据库加压力。
• 维护起来更省心：这张表UPDATE操作相关的所有强约束全在同一个触发器里，后面改规则、排查约束报错的时候，不用翻好几个触发器对象零散找逻辑，也不会出现改规则的时候漏改某一个独立触发器，导致约束前后不一致的问题。抛错提示、操作日志这类通用逻辑也能统一写，不用在3个触发器里重复堆一样的代码。
• 运行逻辑更稳定：单个触发器里的代码是严格按你写的顺序跑的，不会因为数据库版本升级、对象创建顺序变化、配置调整就出现校验错跑、漏跑的问题。要是拆成独立触发器，比如不少MySQL版本里，同优先级的触发器是按创建时间先后执行的，万一有人误删重建了其中一个校验触发器，执行顺序直接就乱了，极端情况甚至会绕开校验产生脏数据。

实操优化提示：用单个触发器不代表要把所有代码全堆在一个块里，你可以把3项独立校验分别封装成独立的存储函数，触发器里只负责按顺序调用、判断返回结果，既保留单触发器的性能和稳定性优势，也能让每段校验逻辑职责清晰，后面改逻辑、做单测都方便。

很多人觉得方案b符合“单一职责”设计原则，但这个思路在数据库触发器场景下不适用：触发器本身就是绑定表写操作的切面逻辑，同触发时机的同类校验本来就属于同一个切面的职责范围，为了形式上的拆分牺牲执行稳定性、增加额外开销，完全是得不偿失。

内容的提问来源于stack exchange，提问作者Dercni