在LINQ-to-SQL中，我应该使用NOLOCK来提高性能吗？

Question

我们的DBA向我们提供了有关我们的LINQ查询在数据库上创建数千个锁的信息。我们的团队的开发人员挖出了这个Hanselman的岗位作为一个可能的解决我们的问题：

http://www.hanselman.com/blog/GettingLINQToSQLAndLINQToEntitiesToUseNOLOCK.aspx

斯科特提供了LINQ 3种方式设置NOLOCK。 1）TransactionScope（首选），2）SPROCS，3）context.ExecuteCommand

我们是一个新闻网站，99％的阅读，1％的写道，所以我们的重点是检索速度。 NOLOCK对我们所有的LINQ-TO-SQL查询来说都是一个很好的策略吗？

我想了解的是为什么使用NOLOCK是或不是一个好主意。必须有许多人拥有相同的目标：快速阅读，很少更新。如果NOLOCK是明显的答案，那为什么它不是默认的？为什么我无法在上下文中将其设置为默认值，而不必在每次数据调用中都设置它？

NOLOCK真的是许多快速读取的最佳选择，很少更新网站？

更新：在SQL Server 2005及更高版本中，快照隔离是否比NOLOCK更好？ 我刚刚发现这个 http://msdn.microsoft.com/en-us/library/ms179599.aspx

覆盖读提交快照。这可以防止写入块，但不会返回脏数据？这应该在90％的时间内用于NOLOCK吗？

更新2：什么是困扰我是干

是最困扰我的是，为了实现无论是无锁或快照模式，我必须改变它在每一个LINQ-TO-的部分SQL查询方法（在更新中使用的除外）。这听起来像是DRY的重大违规行为。

Answer 1

值得注意的是：READ COMMITTED SNAPSHOT（或至少是2年前以前）对于the site you're using已足够好。