LINQ-TO-SQLでは、パフォーマンスを向上させるためにNOLockを使用する必要がありますか？

Question

私たちのDBAは、私たちのLINQクエリがデータベース上で何千ものロックを作成しているという情報を提供しました。私たちのチームの開発者がこのHanselman Postを私たちの問題の可能性のある解決策として掘り下げます：

> http://www.hanselman.com/blog/gettinglinqtosqlandlinqtoentIestousenolock.aspx < / P>

Scottは、nolockを設定するためにLINQで3つの方法を提供します。 1）トランザクションスコープ（優先）、2）スプロック3）context.executecommand

私たちは99％の読み取りのニュースサイトで、1％の書き込みがあるので、私たちの主な焦点は検索の速度です。 nolock すべてのLINQ-to-SQLクエリのための良い戦略は？

私が理解しようとしているのはなぜNolockを使っているのか良い考えではない理由です。私たちの同じ目標を持つ人々がたくさんあるはずです：多くの高速読み取り、更新はほとんどありません。 NOLockが明らかな答えであれば、なぜそれがデフォルトではないのですか？単一のデータコールごとに設定するのではなく、コンテキストのデフォルトでデフォルトにするのはなぜですか？

は、多くの速い読み取りのための本当に最高のオプション、いくつかのアップデートサイト？

アップデート：SQL Server 2005以降では、ノロックよりもスナップショット分離が優れていますか？ 私はこれを見つけました > http://msdn.microsoft.com/en-us/library/ms179599.aspx. 読み取り済みスナップショットをカバーしている

。これによりwriteブロックが防ぎますが、ダーティデータは返されませんか？これはNolockの上の90％を使用するべきですか？

アップデート2：私を悩ませているのは

ほとんどを悩ませている部分は、ノーロックまたはスナップショットパターンを実装するために、すべてのLINQ-to-SQLクエリメソッドで変更する必要があります（アップデートで使用されているものを除く）。これは乾燥の大きな違反のように匂いがします。

Answer 1

Worth noting: READ COMMITTED SNAPSHOT is (or at least was 2+ years ago) good enough for the site you're using.