Sollte ich in LINQ-to-SQL NOLOCK, um die Leistung zu verbessern?

Question

Unsere DBA kam mit Informationen, mit denen unsere Link-Abfragen viele Tausende von Sperren in der Datenbank erstellen. Ein Entwickler in unserem Team gruben diesen Hanselman Post als mögliche Lösung für unser Problem:

http://www.hanselman.com/blog/GETTINGINLINQTOSQLANLINQUTOENTITISTOUSENOLOCK.Aspx < / p>

Scott bietet 3 Wege in LINQ zum Setzen von NOLOCK. 1) TransaktionenKop (bevorzugt), 2) Sprocs, 3) context.executecommand

Wir sind eine Nachrichtenseite, die 99% liest, 1% schreibt, sodass unser Hauptfokus auf der Geschwindigkeit des Abrufs liegt. Ist nolock eine gute Strategie für alle unsere Linq-to-SQL-Abfragen?

Was ich versuche, zu verstehen, ist warum mit Nololock ist oder ist keine gute Idee. Es muss viele Leute mit den gleichen Zielen geben: Viele schnelles liest, wenig bis keine Updates. Wenn NOLOCK die offensichtliche Antwort ist, warum ist es dann nicht der Standardwert? Warum kann ich es nicht standardmäßig im Kontext machen, anstatt ihn in jedem einzelnen Datenanruf einstellen zu müssen?

ist noock wirklich die beste Option für die vielen schnellen Reads, wenige Updates-Site?

update: In SQL Server 2005 und höher ist die Snapshot-Isolation besser als NOLOUCK? Ich habe das gerade gefunden http://msdn.microsoft.com/de-us/library/ms179599.aspx

das deckt liebste Snapshot ab. Dies verhindert den Schreibblock, gibt jedoch keine schmutzigen Daten zurück? Sollte dies 90% der Zeit über dem NOLOCK verwendet werden?

update 2: Was mich stört, ist trocken

Der Teil, der mich am meisten stört, ist, dass ich, um entweder ein No-Lock- oder Snapshot-Muster zu implementieren, ihn auf jeder LINQ-to-SQL-Abfragemethode ändern muss (außer den in Aktualisierungen verwendet werden). Dies riecht nach einem großen Verletzung trockener Verletzung.

Answer 1

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