SQL Server能否在数据事务提交完成后执行触发器？

核心问题本质 #

你遇到的问题根源是：常规DML触发器（包括AFTER类触发器）都属于原事务的一部分，执行时原事务尚未提交，而你的存储过程因为隔离级别配置、跨库查询等原因，读不到同事务未提交的新增数据，同时你又不想改造庞大的现有计算逻辑。

可行解决方案 #

方案1：使用数据库原生「事务提交后触发」特性（推荐，改造量最小） #

不同主流数据库都有对应原生能力，完全满足你「事务提交后再执行计算」的需求，无需轮询Job：

• SQL Server：使用Service Broker异步消息队列
  在use表的AFTER触发器中，向Service Broker队列发送携带变更userid的消息，Service Broker的消息消费逻辑会在原事务提交成功后才触发，此时use表的新数据已经全局可见，直接调用现有存储过程即可。这套逻辑可以封装成标准化脚本，批量部署到多实例，无需每个库单独维护Job。
• MySQL 8.0.19+：直接使用AFTER COMMIT触发器
  官方原生支持提交后触发器，定义后会在事务提交成功后执行，此时读取use表可以拿到全部已提交数据，直接调用现有存储过程即可。
• PostgreSQL：使用LISTEN/NOTIFY机制
  在AFTER触发器中调用pg_notify发送携带userid的事件，事件只会在原事务提交后才会推送给监听进程，你可以部署一个统一的轻量监听进程，接收事件后调用对应库的存储过程即可。

方案2：使用CDC（变更数据捕获）能力（适合多库统一运维场景） #

所有主流数据库都支持原生CDC功能，开启use表的CDC捕获后，所有已提交的变更都会写入CDC日志表：

• 你只需要部署一套统一的CDC消费服务，批量处理所有数据库的变更事件，不需要给每个库单独配置轮询Job，运维成本极低
• 所有CDC事件对应的变更都是已经提交完成的，不会出现读不到新增数据的问题

方案3：低成本兼容现有触发器逻辑（临时过渡方案） #

你之前用AFTER触发器统计不到新数据，大概率是存储过程中使用了WITH (NOLOCK)查询提示、或者数据库开启了读已提交快照隔离（RCSI），同事务内查询默认读快照版本导致的：

• 只需要在触发器调用存储过程前，临时修改当前会话的隔离级别为READ COMMITTED，或者删除存储过程中对应查询的NOLOCK提示，就能读取到同事务未提交的新增数据，不需要修改核心计算逻辑

AFTER触发器的适用场景说明 #

AFTER触发器设计为事务提交前执行，核心适用场景是：

• 同事务内的数据合法性校验，校验不通过可以回滚整个事务
• 同事务内的级联数据更新，保证关联数据的一致性
• 同步写入变更日志，保证日志和业务数据的事务一致性
  它的设计目标就是和原事务绑定，所以不适合你需要事务提交后执行的场景。

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