在 LINQ-To-SQL 中，我应该使用 NOLOCK 来提高性能吗？
我们的 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。这可以防止写块，但不会返回脏数据？ 90% 的时间都应该使用它而不是 NOLOCK 吗？
更新 2：困扰我的是 DRY
最困扰我的部分是，为了实现无锁或快照模式，我必须在每个 LINQ-to-SQL 查询方法上更改它（更新中使用的除外）。这听起来像是对 DRY 的严重违反。
Our DBA came to us with information that our LINQ queries are creating many thousands of locks on the database. A developer on our team dug up this Hanselman post as a possible solution to our problem:
http://www.hanselman.com/blog/GettingLINQToSQLAndLINQToEntitiesToUseNOLOCK.aspx
Scott provides 3 ways in LINQ for setting NOLOCK. 1) TransactionScope (preferred), 2) SPROCS, 3) context.ExecuteCommand
We are a news site that is 99% reads, 1% writes so our major focus is on the speed of retrieval. Is NOLOCK a good strategy for all our LINQ-TO-SQL queries?
What I'm trying to understand is why using NOLOCK is or isn't a good idea. There must be a lot of people with our same goals: many fast reads, little to no updates. If NOLOCK is the obvious answer, then why isn't it the default? Why can't I make it a default on the context, instead of having to set it in every single data call?
Is NOLOCK really the best option for the many fast reads, few updates site?
UPDATE: In SQL Server 2005 and above, Is Snapshot isolation better than NOLOCK?
I just found this
http://msdn.microsoft.com/en-us/library/ms179599.aspx
which covers READ COMMITTED SNAPSHOT. This prevents write-block, but doesn't return dirty data? Should this be used 90% of the time over NOLOCK?
UPDATE 2: What's bothering me is DRY
The part that's bothering me most is that in order to implement either a no-lock or snapshot pattern, I have to change it on EVERY LINQ-to-SQL query method (except those being used in updates). This smells like a major violation of DRY.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
值得注意的是：
READ COMMITTED SNAPSHOT对于您正在使用的网站。Worth noting:
READ COMMITTED SNAPSHOTis (or at least was 2+ years ago) good enough for the site you're using.