Vor der Arbeit an Stack Overflow war ich gegen NOLOCK auf dem Prinzip, dass Sie möglicherweise ein SELECT ausführen könnten mit NOLOCK und erhalten Sie Ergebnisse mit möglicherweise veralteten oder inkonsistenten Daten. Ein zu berücksichtigender Faktor ist, wie viele Datensätze gleichzeitig eingefügt/aktualisiert werden können, wenn ein anderer Prozess möglicherweise Daten aus derselben Tabelle auswählt. Wenn dies häufig vorkommt, besteht eine hohe Wahrscheinlichkeit von Deadlocks, es sei denn, Sie verwenden einen Datenbankmodus wie READ COMMITED SNAPSHOT .
Seitdem habe ich meine Sicht auf die Verwendung von NOLOCK geändert nachdem ich gesehen habe, wie es SELECT verbessern kann Leistung sowie Deadlocks auf einem massiv belasteten SQL Server beseitigen. Es kann vorkommen, dass es Ihnen egal ist, dass Ihre Daten nicht genau zu 100 % festgeschrieben sind, und Sie Ergebnisse schnell zurückerhalten müssen, obwohl sie möglicherweise veraltet sind.
Stellen Sie sich eine Frage, wenn Sie daran denken, NOLOCK zu verwenden :
Enthält meine Abfrage eine Tabelle mit einer hohen Anzahl von INSERT /UPDATE Befehle und ist es mir egal, ob die von einer Abfrage zurückgegebenen Daten diese Änderungen zu einem bestimmten Zeitpunkt möglicherweise nicht enthalten?
Wenn die Antwort nein ist, verwenden Sie NOLOCK um die Leistung zu verbessern.
NOLOCK durchgeführt Schlüsselwort innerhalb der Codebasis für Stack Overflow und hat 138 Instanzen gefunden, also verwenden wir es an ziemlich vielen Stellen. 
