To NOLOCK or NOT to NOLOCK, that is the question

Question

This is really more of a discussion than a specific question about nolock.

I took over an app recently that almost every query (and there are lots of them) has the noloc

Answer 1

You should only use nolock on an unchanging table. Of course, this will be the same then as Read Committed Snapshot. Without the snapshot, you are only saving the time it takes to apply a shared lock, and then to remove it, which for most cases isn't necessary.

As for a changing table... No lock doesn't just mean getting a row before a transaction is done updating all of its rows. You can get ghost data as data pages split, or even index pages split. Or no data. That alone scared me away, but I think there may be even more scenarios where you simply get the wrong data.

Of course, nolock for getting rough estimates or to just check in on a process might be reasonable.

Basic rule of thumb -- if you care about the data at all, and the data is changing, then do not use NoLOCK.