Przed pracą nad Stack Overflow byłem przeciwny NOLOCK na zleceniodawcy, który potencjalnie mógłbyś wykonać SELECT z NOLOCK i odzyskaj wyniki z danymi, które mogą być nieaktualne lub niespójne. Czynnikiem do rozważenia jest to, ile rekordów może być wstawionych/zaktualizowanych w tym samym czasie, kiedy inny proces może wybierać dane z tej samej tabeli. Jeśli zdarza się to często, istnieje duże prawdopodobieństwo zakleszczenia, chyba że używasz trybu bazy danych, takiego jak READ COMMITED SNAPSHOT .
Od tego czasu zmieniłem moje spojrzenie na używanie NOLOCK po obejrzeniu, jak może ulepszyć SELECT wydajność, a także wyeliminować zakleszczenia na masowo obciążonym serwerze SQL Server. Czasami możesz nie dbać o to, że Twoje dane nie są dokładnie w 100% zatwierdzone i potrzebujesz szybkich wyników, nawet jeśli mogą być nieaktualne.
Zadaj sobie pytanie, gdy myślisz o użyciu NOLOCK :
Czy moje zapytanie zawiera tabelę z dużą liczbą INSERT? /UPDATE poleceń i czy obchodzi mnie, czy dane zwrócone z zapytania mogą w danym momencie nie zawierać tych zmian?
Jeśli odpowiedź brzmi nie, użyj NOLOCK w celu poprawy wydajności.
NOLOCK słowa kluczowego w bazie kodu dla Stack Overflow i znaleźliśmy 138 wystąpień, więc używamy go w wielu miejscach. 
