Aaron Bertrand shares examples:
This is not another “NOLOCK can show you dirty data” rant. There are plenty of posts about that, usually explaining how the hint is a misnomer because it doesn’t really mean “no” locks, how dirty or phantom data can sneak into a report and render it inaccurate, and why RCSI is often a much better solution to reader/writer conflicts.
No, I’ve largely given up trying to swim against the current and fight draconian policies that have taught everyone, far and wide, the commandment:
THOU SHALT USE NOLOCK ON EVERY TABLE REFERENCE.
EVER.
UNTIL THE END OF DAYS.
I don’t know where people learned this, but it certainly feels that way in, well, every place I’ve worked, either as a full-time employee or as a consultant. In each case, it’s been a long road to get them down RCSI, removing NOLOCK, and realizing that things are better.
By the way, I’m glad Aaron included the two non-examples of UPDATE and DELETE with NOLOCK, as I’ve seen cases of this in the wild as well, even though it (thankfully) has zero impact because SQL Server ignores the hint.