Innan jag arbetade med Stack Overflow var jag emot NOLOCK på principen att du potentiellt skulle kunna utföra en SELECT med NOLOCK och få tillbaka resultat med data som kan vara inaktuella eller inkonsekventa. En faktor att tänka på är hur många poster som kan infogas/uppdateras samtidigt som en annan process kan välja data från samma tabell. Om detta händer mycket finns det en hög sannolikhet för dödläge om du inte använder ett databasläge som READ COMMITED SNAPSHOT .
Jag har sedan dess ändrat mitt perspektiv på användningen av NOLOCK efter att ha sett hur det kan förbättra SELECT prestanda samt eliminera dödlägen på en massivt laddad SQL Server. Det finns tillfällen då du kanske inte bryr dig om att din data inte är exakt 100 % säkrad och du behöver snabbt tillbaka resultaten även om de kan vara inaktuella.
Ställ dig själv en fråga när du funderar på att använda NOLOCK :
Innehåller min fråga en tabell som har ett högt antal
INSERT/UPDATEkommandon och bryr jag mig om data som returneras från en fråga kanske saknar dessa ändringar vid ett givet tillfälle?
Om svaret är nej, använd NOLOCK för att förbättra prestandan.
NOLOCK nyckelordet i kodbasen för Stack Overflow och hittade 138 instanser, så vi använder det på ganska många ställen.