我们的 DBA 向我们提供了我们的 LINQ 查询正在数据库上创建数千个锁的信息。我们团队的一位开发人员挖掘了这个 Hanselman 帖子作为我们问题的可能解决方案：
http://www.hanselman.com/blog/GettingLINQToSQLAndLINQToEntitiesToUseNOLOCK.aspx
Scott 在 LINQ 中提供了 3 种方式来设置 NOLOCK。1) TransactionScope (首选), 2) SPROCS, 3) context.ExecuteCommand
我们是一个 99% 读取率、1% 写入率的新闻网站，因此我们的主要关注点是检索速度。对于我们所有的 LINQ-TO-SQL 查询来说，NOLOCK是一个好的策略吗？
我试图理解的是为什么使用 NOLOCK 是或不是一个好主意。肯定有很多人有着相同的目标：很多快速阅读，很少甚至没有更新。如果 NOLOCK 是显而易见的答案，那么为什么它不是默认值呢？为什么我不能在上下文中将其设为默认值，而不必在每个数据调用中都设置它？
NOLOCK 真的是许多快速阅读、很少更新网站的最佳选择吗？
更新：在 SQL Server 2005 及更高版本中，快照隔离是否比 NOLOCK 更好？ 我刚刚发现这个 http://msdn.microsoft.com/en-us/library/ms179599.aspx
其中包括READ COMMITTED SNAPSHOT。这可以防止写块，但不返回脏数据？是否应该在 NOLOCK 上 90% 的时间使用它？
更新 2：困扰我的是 DRY
最困扰我的部分是，为了实现无锁或快照模式，我必须在每个 LINQ-to-SQL 查询方法上更改它（更新中使用的方法除外）。这闻起来像是对 DRY 的重大违反。