是否建议对只读操作设置XACT_ABORT ON？含只读操作的存储过程需开启吗？

1. 是否建议针对只读操作设置XACT_ABORT为"ON"？ #

一句话总结：建议开启，但不是硬性要求。

先掰扯清楚XACT_ABORT的核心作用：它会在SQL执行遇到严重错误（比如锁超时、语法错误、违反约束这类）时，自动回滚当前事务并终止会话。对只读操作来说，虽然不会修改数据，但开启它有不少实际好处：

• 避免「事务悬挂」：比如你跑一个复杂的多表关联查询，中途遇到锁超时，XACT_ABORT ON会立刻终止会话，不会让事务卡在半吊子状态，浪费数据库资源。
• 统一错误处理逻辑：如果你的代码里既有读写操作又有只读操作，统一开XACT_ABORT能让错误处理更一致，不用来回切换设置。
• 远程查询更靠谱：要是用到链接服务器查数据，XACT_ABORT ON能确保远程查询出错时及时释放资源，不会拖慢本地会话。

当然，如果你只是跑个超级简单的查询（比如SELECT * FROM Users WHERE Id = 1），而且几乎不可能出错，不开也没啥大问题。但从最佳实践角度，开启它绝对是利大于弊的。

2. 若存储过程仅包含只读操作，是否需要将XACT_ABORT设置为"ON"？ #

答案：推荐设置，但可以根据具体场景灵活调整。

哪怕是纯只读的存储过程，开启XACT_ABORT的好处也很实在：

• 防止意外的事务残留：比如存储过程里有好几步查询，其中某一步报错了，XACT_ABORT ON会直接终止整个存储过程，不会让后面的查询继续瞎跑，避免产生混乱的结果或者占用不必要的资源。
• 错误排查更省心：存储过程报错时，开启XACT_ABORT会让错误信息更直接，不会因为事务还在继续执行而掩盖真正的问题根源。
• 符合官方最佳实践：微软的文档里明确提到，不管存储过程是读写还是只读，开启XACT_ABORT都是推荐做法，尤其是在生产环境这种需要可靠性的地方。

不过也有极少数情况可以考虑不开启：比如这个存储过程是个极端轻量的固定查询，你能100%确保不会出错；或者你需要自定义错误处理，希望某个步骤出错后继续执行后续逻辑——但这种场景真的很少见，大部分时候还是开着更稳妥。

快速设置示例 #

如果要在只读存储过程里开启，只需要在开头加一行：

SET XACT_ABORT ON;

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