问nolock/TransactionScope与快照隔离

EN

首先，NoLock (和ReadUncommitted)是极其危险的。想一想，你之所以使用事务，主要是因为你想让你的数据保持一致。通过使用NoLock，您允许对您的数据进行脏读。比方说，在您的应用程序中，读取半更新或半插入的数据的可能性很大。您的应用程序(或用户)将根据不一致的数据做出决策。

如果你去企业，简单地问你的应用程序处理的数据是否会不一致，我相信答案肯定是不一致的。所以不要走这条路，我们已经走过了，它无处可寻。

现在来看一下顺序。据我所知，理论上不能保证它的顺序总是相同的，但实际上可能是这样的(因为ORM通常只有一种算法来枚举实体和发现更改)。但它并没有真正的帮助，因为即使它以相同的顺序枚举实体(为了找到需要保存的内容)，实体类型的数量也可能不同。比方说，在一个场景中是A和D，在另一个场景中是A，B，D，在另一个场景中是A，C，D。现在它可能依赖于这些实体之间的关系。比方说，C依赖于D，所以实际的顺序实际上是A，D，C，而不是A，C，D(即使在这里也没有指定它不是D，C，A)。因此，转接此订单不是一种选择。唯一能确保顺序的事情就是在每一步之后调用.SaveChanges()，这很糟糕。

可以，您可以使用Snapshot隔离级别(有两个，基本上是任何一个，尝试Snapshot Read Committed)。它将极大地减少系统中的死锁数量，但这种方法有其自身的缺点。

为了或多或少恰当地解决这个问题，我建议您在系统中清楚地定义事务边界。系统的哪个部分“拥有”哪些数据？哪些数据必须与其他数据保持一致？然后你就可以说“只允许这些交易”和“只允许我的系统的这个特定部分接触这个特定的数据”。

这很难，特别是在刚开始的时候，当你有一个大的数据库，读写混乱，所有东西都来自任何地方。但它会使系统更加稳定、可控和可维护。

顺便说一句，Udi Dahan有一篇关于这方面的有趣的博客文章：Inconsistent data, poor performance, or SOA – pick one