Was bedeutet "with (nolock)" in SQL Server?

Question

Kann jemand erklären, welche Auswirkungen die Verwendung von with (nolock) bei Abfragen, wann sollte man sie verwenden und wann nicht?

Wenn Sie z. B. eine Bankanwendung mit hohen Transaktionsraten und vielen Daten in bestimmten Tabellen haben, für welche Arten von Abfragen wäre nolock dann in Ordnung? Gibt es Fälle, in denen man es immer/keinesfalls verwenden sollte?

Answer 1

NOLOCK ist gleichbedeutend mit READ UNCOMMITTED Microsoft sagt jedoch, dass Sie es nicht verwenden sollten für UPDATE o DELETE Erklärungen:

Für UPDATE- oder DELETE-Anweisungen: Diese Funktion wird in einer zukünftigen Version von Microsoft SQL Server entfernt werden. Vermeiden Sie die Verwendung dieser Funktion bei Neuentwicklungen und planen Sie die Änderung von Anwendungen, die diese Funktion derzeit verwenden.

http://msdn.microsoft.com/en-us/library/ms187373.aspx

Dieser Artikel bezieht sich auf SQL Server 2005, so dass die Unterstützung für NOLOCK existiert, wenn Sie diese Version verwenden. Um Ihren Code zukunftssicher zu machen (vorausgesetzt, Sie haben sich für die Verwendung von Dirty Reads entschieden), können Sie dies in Ihren gespeicherten Prozeduren verwenden:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

Answer 2

Sie können es verwenden, wenn Sie nur Daten lesen und sich nicht wirklich darum kümmern, ob Sie möglicherweise Daten zurückbekommen, die noch nicht übertragen wurden.

Sie kann bei Lesevorgängen schneller sein, aber ich kann nicht sagen, um wie viel.

Im Allgemeinen empfehle ich, sie nicht zu verwenden - das Lesen von nicht gebundenen Daten kann bestenfalls ein wenig verwirrend sein.

Answer 3

Ein weiterer Fall, in dem dies normalerweise in Ordnung ist, ist eine Berichtsdatenbank, in der die Daten vielleicht schon gealtert sind und einfach nicht mehr geschrieben werden. In diesem Fall sollte die Option jedoch vom Administrator auf Datenbank- oder Tabellenebene eingestellt werden, indem er die Standardisolierungsebene ändert.

Im allgemeinen Fall: Sie können es verwenden, wenn Sie très sicher sein, dass es in Ordnung ist, alte Daten zu lesen. Das Wichtigste ist, dass die das kann man sehr leicht falsch verstehen . Selbst wenn es zu dem Zeitpunkt, zu dem Sie die Abfrage schreiben, in Ordnung ist, sind Sie sicher, dass sich in der Zukunft nichts an der Datenbank ändern wird, so dass diese Aktualisierungen wichtiger werden?

Ich schließe mich auch der Meinung an, dass es wahrscheinlich no eine gute Idee für eine Banking-App. Oder in einer Inventar-App. Oder überall dort, wo Sie über Transaktionen nachdenken.

Answer 4

Kurze Antwort:

Verwenden Sie nur WITH (NOLOCK) in SELECT-Anweisung auf Tabellen, die einen geclusterten Index haben.

Lange Antwort:

WITH(NOLOCK) wird oft als magischer Weg ausgenutzt, um das Lesen von Datenbanken zu beschleunigen.

Die Ergebnismenge kann Zeilen enthalten, die noch nicht festgeschrieben wurden, und die oft später zurückgenommen werden.

Wenn WITH(NOLOCK) auf eine Tabelle angewendet wird, die einen nicht geclusterten Index hat, können Zeilenindizes von anderen Transaktionen geändert werden, während die Zeilendaten in die Ergebnistabelle gestreamt werden. Dies bedeutet, dass in der Ergebnismenge Zeilen fehlen können oder dieselbe Zeile mehrfach angezeigt wird.

READ COMMITTED fügt ein zusätzliches Problem hinzu, bei dem Daten innerhalb einer einzelnen Spalte beschädigt werden, wenn mehrere Benutzer dieselbe Zelle gleichzeitig ändern.

Answer 5

Einfache Antwort: immer dann, wenn Ihr SQL keine Daten ändert und Sie eine Abfrage haben, die andere Aktivitäten beeinträchtigen könnte (durch Sperren).

Es lohnt sich, dies bei allen Abfragen für Berichte in Betracht zu ziehen, insbesondere wenn die Abfrage mehr als, sagen wir, 1 Sekunde dauert.

Dies ist besonders nützlich, wenn Sie OLAP-artige Berichte gegen eine OLTP-Datenbank laufen lassen.

Die erste Frage, die man sich stellen sollte, ist jedoch: "Warum mache ich mir darüber Gedanken?" Meiner Erfahrung nach wird das Standard-Sperrverhalten oft manipuliert, wenn jemand im "Alles-ausprobieren"-Modus ist, und dies ist ein Fall, in dem unerwartete Konsequenzen nicht unwahrscheinlich sind. Allzu oft handelt es sich dabei um eine verfrühte Optimierung, die allzu leicht in eine Anwendung eingebettet werden kann, "nur für den Fall der Fälle". Es ist wichtig zu verstehen, warum man dies tut, welches Problem damit gelöst wird und ob man das Problem tatsächlich hat.