Преди да работя върху Stack Overflow, бях против NOLOCK на принципала, че потенциално бихте могли да извършите SELECT с NOLOCK и да получите обратно резултати с данни, които може да са остарели или непоследователни. Фактор, върху който трябва да помислите, е колко записа могат да бъдат вмъкнати/актуализирани по едно и също време друг процес може да избира данни от същата таблица. Ако това се случва често, тогава има голяма вероятност от блокиране, освен ако не използвате режим на база данни като READ COMMITED SNAPSHOT .
Оттогава промених гледната си точка за използването на NOLOCK след като видях как може да подобри SELECT производителност, както и премахване на блокиране на масово натоварен SQL Server. Има моменти, в които може да не ви пука, че вашите данни не са точно 100% ангажирани и имате нужда от резултати бързо, въпреки че може да са остарели.
Задайте си въпрос, когато мислите да използвате NOLOCK :
Моята заявка включва ли таблица, която има голям брой
INSERT/UPDATEкоманди и интересува ли ме дали данните, върнати от заявка, може да липсват тези промени в даден момент?
Ако отговорът е не, тогава използвайте NOLOCK за подобряване на производителността.
NOLOCK ключова дума в кодовата база за Stack Overflow и открихме 138 екземпляра, така че я използваме на доста места. 
