SQL Server 中嵌套事务的隔离范围是什么？答案

【问题标题】：What is the scope of isolation in nested transactions in SQL Server?SQL Server 中嵌套事务的隔离范围是什么？
【发布时间】：2010-09-18 09:58:51
【问题描述】：

考虑以下 SQL：

开始传输设置事务隔离级别读取已提交插入乐队（姓名）选择“Depeche 模式” 联盟选择“街机火灾” -- 我已经缩进了内部事务以使其更清晰。开始传输设置事务隔离级别读取未提交选择 * 从乐队犯罪 -- 这里的隔离级别是多少？更新乐队 SET Name = '谦虚的老鼠' WHERE Name = 'Oddest House' 犯罪

总而言之，我们启动一个事务并将其隔离级别设置为READ COMMITTED。然后我们执行一些随机 SQL 并启动另一个嵌套事务。在这个事务中，我们将隔离级别更改为READ UNCOMMITTED。然后我们提交该事务并返回到另一个。

现在，我的猜测是，在内部提交之后，隔离级别会返回到READ COMMITTED。这是正确的吗？

【问题讨论】：

标签： sql-server transactions

【解决方案1】：

我不认为这是正确的。

参考这里的备注：Set Transaction

只有一种隔离级别选项可以一次设置，它保持为该连接设置，直到它已明确更改。

【讨论】：

【解决方案2】：

你 [Bob Probst] 是对的。有趣的是，根据您链接的documentation：

如果您在存储过程或触发器中发出 SET TRANSACTION ISOLATION LEVEL，则当对象返回控制权时，隔离级别将重置为调用对象时有效的级别。例如，如果您在批处理中设置 REPEATABLE READ，然后批处理调用将隔离级别设置为 SERIALIZABLE 的存储过程，则当存储过程将控制权返回给批处理时，隔离级别设置将恢复为 REPEATABLE READ。

所以，这里的底线是 SET TRANSACTION ISOLATION LEVEL 具有 过程亲和性，而不是 事务亲和性（正如我所想的那样）。

太棒了！

【讨论】：

那太糟糕了，哈哈！我的 C# 数据库 API 倾向于接受打开的连接对象，因此我可以调用多个函数而无需每次都打开新连接。这种“事务关联性”的缺失意味着，如果我从另一个数据库 API 方法调用一个数据库 API 方法，并且两者都使用一个事务，那么嵌套事务可能会改变调用者事务的事务隔离级别。绝对烂。解决方法...对于任何使用事务的 C# 方法，通过保存隔离级别（dbcc 用户选项）并在返回之前恢复它，使用 C# 代码模拟 C# 事务的过程亲和性！
这个“anwer”应该是一条评论。但是让我休息一下。那是 2008 年。:)