Ist der NOLOCK (SQL Server Tipp) schlechte Praxis?

Question

Ich bin im Geschäft, Website und Anwendungen zu erstellen, die sind nicht Mission kritisch -> zB. Bankensoftware, Weltraumflug, Anwendung zur Überwachung der Intensivpflege usw. Sie erhalten die Idee.

Ist es mit diesem massiven Haftungsausschluss mit dem Nolock -Hinweis in einer SQL -Erklärung schlecht? Vor einigen Jahren wurde von einem Mit -SQL -Administrator vorgeschlagen, dass ich Nolock verwenden sollte, wenn ich mit einer "schmutzigen Lektüre" zufrieden bin, die mir ein bisschen mehr Leistung aus meinem System gibt Tabelle/Zeile/was auch immer.

Mir wurde auch gesagt, dass es eine großartige Lösung ist, wenn ich tödliche Locks erlebe. Also begann ich ein paar Jahre lang diesem Gedanken zu folgen, bis ein SQL -Guru mir mit einem zufälligen Code half und alle Nolocks in meinem SQL -Code bemerkte. Ich wurde höflich beschimpft und er versuchte es mir zu erklären (warum es keine gute Sache ist) und ich ging irgendwie verloren. Ich hatte das Gefühl, dass die Essenz seiner Erklärung lautete: „Es ist eine Band-Aid-Lösung für ein ernsthafteres Problem. Vor allem, wenn Sie eine Deadlockung haben. Beheben Sie daher die Wurzel des Problems.

Ich habe kürzlich etwas gegoogelt und bin begegnet dieser Beitrag.

Kann mir ein paar SQL DB Guru Sensei bitte aufklären?

Answer 1

Mit Nolock -Hinweis das Transaktions -Isolationsniveau für die SELECT Aussage ist READ UNCOMMITTED. Dies bedeutet, dass die Abfrage schmutzige und inkonsistente Daten sehen kann.

Dies ist keine gute Idee, sich als Regel zu bewerben. Auch wenn dieses schmutzige Leseverhalten für Ihre geschäftskritische webbasierte Anwendung in Ordnung ist, kann ein NOLOCK -Scan einen Fehler von 601 verursachen, der die Abfrage aufgrund der Datenbewegung aufgrund mangelnder Verriegelungsschutz beendet.

Ich schlage vor, zu lesen Wenn die Snapshot -Isolation hilft und wenn sie weh tut - Die MSDN empfiehlt unter den meisten Umständen die Verwendung von LEAD -Snapshot anstelle von Snapshot.

Answer 2

Bevor ich an Stack Overflow arbeitete, war ich dagegen NOLOCK auf dem Schulleiter, den Sie möglicherweise eine ausführen können SELECT mit NOLOCK und erhalten Sie die Ergebnisse mit Daten, die möglicherweise veraltet oder inkonsistent sind. Ein Faktor, über den Sie nachdenken sollten, ist, wie viele Datensätze gleichzeitig eingefügt/aktualisiert werden können. Ein anderer Prozess kann die Auswahl von Daten aus derselben Tabelle sein. Wenn dies viel passiert, besteht eine hohe Wahrscheinlichkeit von Deadlocks, es sei denn, Sie verwenden einen Datenbankmodus wie z. READ COMMITED SNAPSHOT.

Ich habe seitdem meine Sichtweise auf die Verwendung von NOLOCK Nachdem sie gesehen haben, wie es sich verbessern kann SELECT Leistung und eliminieren Sie Deadlocks auf einem massiv geladenen SQL -Server. Es gibt Zeiten, in denen es Ihnen möglicherweise egal ist, dass Ihre Daten nicht genau 100% festgelegt sind und Sie schneller Ergebnisse benötigen, obwohl sie möglicherweise veraltet sind.

Stellen Sie sich eine Frage, wenn Sie darüber nachdenken NOLOCK:

Enthält meine Abfrage eine Tabelle, die eine hohe Anzahl von Anzahl hat? INSERT/UPDATE Befehle und kümmert es mich, ob die Daten, die aus einer Abfrage zurückgegeben wurden, diese Änderungen möglicherweise zu einem bestimmten Zeitpunkt fehlen?

Wenn die Antwort nein ist, verwenden Sie NOLOCK Leistung zu verbessern.

---

Ich habe gerade eine schnelle Suche nach dem durchgeführt NOLOCK Schlüsselwort in der Codebasis für Stack -Überlauf und fand 138 Instanzen. Daher verwenden wir es an einigen Stellen.

Answer 3

Wenn Sie sich nicht für schmutzige Lesevorgänge interessieren (dh in einer überwiegend Lessituation), dann dann NOLOCK ist gut.

ABER, Beachten Sie, dass die Mehrheit der Sperrenprobleme darauf zurückzuführen ist, dass Sie nicht über die „korrekten“ Indizes für Ihre Abfrage -Arbeitsbelastung verfügen (vorausgesetzt, die Hardware entspricht der Aufgabe).

Und die Erklärung des Gurus war korrekt. Es ist in der Regel eine Band-Aid-Lösung für ein ernsthafteres Problem.

Bearbeiten: Ich schlage definitiv nicht vor, dass Nolock verwendet werden sollte. Ich denke, ich hätte das offensichtlich klar machen sollen. (Ich würde es immer nur unter extremen Umständen verwenden, in denen ich analysiert hatte, dass es in Ordnung war). Vor einiger Zeit habe ich an einem TSQL gearbeitet, das mit Nolock bestreut worden war, um die Verriegelungsprobleme zu lindern. Ich habe sie alle entfernt, die richtigen Indizes implementiert und alle Deadlocks verschwanden.

Answer 4

Zweifel, es war ein "Guru", der Erfahrung im hohen Verkehr hatte ...

Websites sind normalerweise "schmutzig", wenn die Person die vollständig geladene Seite anzeigt. Betrachten Sie ein Formular, das aus der Datenbank lädt und dann die Daten speichert, die bearbeitet werden? Es ist idiotisch, wie Menschen über schmutzige Leads weitermachen, wenn es darum geht, so ein Nein zu sein.

Wenn Sie jedoch eine Reihe von Schichten auf Ihren Auswahl bauen, können Sie in einer gefährlichen Redundanz aufbauen. Wenn Sie sich mit Geld- oder Status -Szenarien befassen, müssen Sie nicht nur Transaktionsdaten lesen/schriftlich, sondern auch eine ordnungsgemäße Parallelitätslösung (etwas "Gurus", mit dem Sie sich nicht beschäftigen).

Auf der anderen Seite, wenn Sie eine fortschrittliche Produktsuche nach einer Website haben (dh etwas, das wahrscheinlich nicht zwischenstrahlt und ein wenig intensiv ist) und Sie jemals eine Website mit mehr als wenigen gleichzeitigen Benutzern erstellt haben (Phänominal wie viele "Experten" nicht), es ist lächerlich, jeden anderen Prozess dahinter zu füllen.

Wissen Sie, was es bedeutet, und verwenden Sie es gegebenenfalls. Ihre Datenbank wird heutzutage fast immer Ihr Hauptflaschenhals sein. Wenn Sie in der Verwendung von Nolock klug sind, können Sie Tausende in der Infrastruktur ersparen.

BEARBEITEN: Es sind nicht nur Deadlocks, bei denen es hilft, sondern auch, wie viel Sie alle anderen warten lassen, bis Sie fertig sind, oder umgekehrt.

Verwenden Sie Nolock -Hinweis in EF4?

Answer 5

Keine der Antworten ist falsch, wie ein wenig verwirrend vielleicht ist.

• Wenn Sie einzelne Werte/Zeilen abfragen, ist dies stets Schlechte Praxis für die Verwendung von Nolock - Sie möchten wahrscheinlich nie falsche Informationen anzeigen oder möglicherweise sogar Maßnahmen zu falschen Daten ergreifen.
• Bei der Anzeige grobe statistische Informationen kann Nolock sehr nützlich sein. Nehmen Sie dies als Beispiel: Es wäre Unsinn, Schlösser zu nehmen, um das zu lesen genau Anzahl der Ansichten einer Frage oder der genauen Anzahl von Fragen für ein Tag. Niemand kümmert sich darum, wenn Sie fälschlicherweise 3360 Fragen mit dem Tag "SQL-Server" und aufgrund eines Transaktionsrollbacks 3359 Fragen eine Sekunde später fälschlicherweise angeben.

Answer 6

Als professioneller Entwickler würde ich sagen, dass es hängt. Aber ich folge definitiv Gats und Omg Ponies Rat. Wissen, was Sie tun, wissen Sie, wann es hilft und wann es weh tut und

lesen Hinweise und andere schlechte Ideen

Was könnte Sie dazu bringen, den SQL -Server tiefer zu verstehen? Ich folge im Allgemeinen der Regel, dass SQL -Hinweise böse sind, aber leider benutze ich sie ab und zu, wenn ich es satt habe, SQL Server zu zwingen, Dinge zu tun ... aber das sind seltene Fälle.

Lukas

Answer 7

Als App-Support Ad-Hock-Abfragen aus dem Produktionserver mit SSMs (die nicht über die Berichterstattung versorgt wurden) beantworten wollte, forderte ich sie auf, Nolock zu verwenden. Auf diese Weise ist das 'Hauptgeschäft' nicht betroffen.

Answer 8

Ich stimme einigen Kommentaren zu Nolock Hinweis und vor allem mit denjenigen zu, die sagen "Verwenden Sie es, wenn es angemessen ist". Wenn die Anwendung schlecht geschrieben wird und eine unangemessene Art und Weise verwendet, kann dies zu einer Eskalation der Sperrung führen. Eine hochtransaktionale Tabelle wird aufgrund ihrer Natur ständig gesperrt. Eine gute Indexabdeckung hilft nicht beim Abrufen der Daten, aber das Setzen von Isolationsstufen zum Lesen von Unbekanntes tut dies. Ich glaube auch, dass die Verwendung von Nolock -Hinweis in vielen Fällen sicher ist, wenn die Art der Veränderungen vorhersehbar ist. Zum Beispiel - im Fertigung, wenn Jobs mit Reisenden mit vielen Messeinsätzen verschiedene Prozesse durchlaufen /Seite. Die in diesem Fall zugegriffenen Daten sind statisch, können sich jedoch in einer sehr Transaktionstabelle mit Hunderten von Millionen Datensätzen und Tausendenaktualisierungen/Einfügen pro Minute befinden. Prost

Answer 9

Ich glaube, dass es praktisch nie korrekt ist, Nolock zu verwenden.

Wenn Sie eine einzelne Zeile lesen, bedeutet der korrekte Index, dass Sie Nolock nicht benötigen, da die einzelnen Zeilenaktionen schnell abgeschlossen sind.

Wenn Sie viele Zeilen für etwas anderes als vorübergehende Anzeige lesen und sich darum kümmern können, das Ergebnis zu wiederholen oder durch die erzeugte Anzahl zu verteidigen, ist Nolock nicht angemessen.

Nolock ist ein Ersatz -Tag für "Es ist mir egal, ob diese Antwort doppelte Zeilen, Zeilen enthält, die gelöscht werden, oder Zeilen, die nie wegen Rollback eingefügt wurden."

Fehler, die unter Nolock möglich sind:

• Zeilen, die übereinstimmen, werden überhaupt nicht zurückgegeben.
• Einzelne Zeilen werden mehrmals zurückgegeben (einschließlich mehrerer Instanzen desselben Primärschlüssels)
• Zeilen, die nicht übereinstimmen, werden zurückgegeben.

Jede Aktion, die eine Seite aufgeteilt kann, während die Nolock -Auswahl ausgeführt wird, kann dazu führen, dass diese Dinge auftreten. Fast jede Aktion (sogar ein Löschen) kann zu einer Seite geteilt werden.

Deshalb: Wenn Sie "wissen", dass die Zeile während des Laufens nicht geändert wird, verwenden Sie Nolock nicht, da ein Index ein effizientes Abrufen ermöglicht.

Wenn Sie den Verdacht haben, dass sich die Reihe ändern kann, während die Abfrage ausgeführt wird, und Sie sich für die Genauigkeit interessieren, verwenden Sie Nolock nicht.

Wenn Sie Nolock wegen Deadlocks in Betracht ziehen, untersuchen Sie die Abfrageplanstruktur für unerwartete Tisch -Scans, verfolgen Sie die Sackgassen und sehen Sie, warum sie auftreten. Nolock Around Writes kann bedeuten, dass Fragen, die bisher abgestimmt wurden, möglicherweise beide die falsche Antwort schreiben.

Answer 10

Die besseren Lösungen sind nach Möglichkeit:

• Replizieren Sie Ihre Daten (mithilfe der Protokollreplikation) in einer Berichtsdatenbank.
• Verwenden Sie San Snapshots und montieren Sie eine konsistente Version des DB
• Verwenden Sie eine Datenbank, die eine bessere grundlegende Transaktions -Isolationsstufe aufweist

Das Snapshot -Transaktions -Isolationsniveau wurde erstellt, da MS den Umsatz an Oracle verlor. Oracle verwendet undo/Redo -Protokolle, um dieses Problem zu vermeiden. Postgres verwendet MVCC. In der Zukunft wird Heckaton von MS MVCC einsetzen, aber das ist Jahre davon entfernt, die Produktion bereit zu sein.

Answer 11

Nolock wird oft als magische Methode ausgenutzt, um Datenbank -Lesevorgänge zu beschleunigen, aber ich versuche, sie zu vermeiden, wenn es möglich ist.

Das Ergebnissatz kann Zeilen enthalten, die noch nicht begangen wurden und oft später zurückgerollt werden.

Ein Fehler oder eine Ergebnismenge kann leer sein, Zeilen fehlen oder die gleiche Zeile mehrmals anzeigen.

Dies liegt daran, dass andere Transaktionen gleichzeitig Daten verschieben, die Sie lesen.

LEAD FITTED fügt ein zusätzliches Problem hinzu, bei dem Daten in einer einzigen Spalte beschädigt werden, in der mehrere Benutzer dieselbe Zelle gleichzeitig ändern.

Answer 12

Im wirklichen Leben, in dem Sie bereits auf Systeme geschrieben haben und Tabellen hinzuzufügen, verlangsamt sich die Datenbelastung einer 14 -GIG -Datentabelle drastisch. , zählen usw.) Treiben Sie keine Zeile, Seite, Tabellenverriegelung und verschlechtern Sie die Gesamtleistung. Einfach zu sagen, dass in einem neuen System nie mit Nolock verwendet wird und Indizes verwendet wird. Fügen Sie jedoch die Daten des Daten zu einem strengen Herunterladen von Daten zu. Wenn ich dann gesagt werde, ändern Sie die Codebasis, um die Indizes zu löschen, und dann die Last der Masse und dann die Indizes neu zu erstellen - welche ist alles gut und gut, wenn Sie ein neues System entwickeln. Aber nicht, wenn Sie bereits ein System haben.