在SQL Server触发器中使用RETURN语句是否安全？

先帮你理清楚整个问题的来龙去脉，再针对你担心的脏读问题给出明确结论：

为什么空触发器会导致锁持有时间延长？ #

当你的表上存在触发器时，SQL Server会把触发器的执行逻辑纳入INSERT（或其他触发操作）的事务上下文里。哪怕触发器是空的（只有BEGIN SET NOCOUNT ON; END），SQL Server也会走完触发器的执行流程，这会导致INSERT操作对Table1持有的排他锁，一直保持到整个事务提交才释放。而禁用触发器后，INSERT语句执行完成就会释放锁，后续的SELECT不会被阻塞，自然也就不会触发死锁。

RETURN语句在这里的作用 #

你查到的微软文档说RETURN会“释放触发器”，其实本质是提前终止触发器的执行流程。当触发器执行到RETURN时，SQL Server会结束触发器的处理，让锁的释放逻辑回到没有触发器时的状态——也就是INSERT语句完成后就释放锁，而不是等到整个事务提交。这就解决了你遇到的死锁问题。

触发器修改自身表时，RETURN会导致脏读吗？ #

答案是：不会，只要你的事务隔离级别设置合理，完全不用担心脏读风险，原因如下：

• 脏读的核心是读取到其他事务未提交的数据，这只和事务的隔离级别有关，和触发器里的RETURN语句无关。默认的READ COMMITTED隔离级别（SQL Server默认）会阻止脏读，要么通过锁机制，要么通过行版本控制（如果开启了READ_COMMITTED_SNAPSHOT）。
• 哪怕触发器修改了自身所属的表，整个操作依然在同一个事务中。RETURN只是提前结束触发器，并不会提交事务——未提交的修改依然处于事务保护下，其他事务在READ COMMITTED及以上隔离级别下，根本看不到这些未提交的数据，自然不会出现脏读。
• 只有当你主动使用READ UNCOMMITTED隔离级别时，才可能读取到未提交数据，但这是隔离级别的选择问题，和RETURN没关系。

总结 #

在触发器末尾添加RETURN语句是完全安全的：它既解决了空触发器导致的死锁问题，又不会因为修改自身表而引入脏读风险。只要保持默认的隔离级别设置，就不用有任何顾虑。

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