Prior to working on Stack Overflow, I was against NOLOCK
on the principal that you could potentially perform a SELECT
with NOLOCK
and get back results with data that may be out of date or inconsistent. A factor to think about is how many records may be inserted/updated at the same time another process may be selecting data from the same table. If this happens a lot then there’s a high probability of deadlocks unless you use a database mode such as READ COMMITED SNAPSHOT
.
I have since changed my perspective on the use of NOLOCK
after witnessing how it can improve SELECT
performance as well as eliminate deadlocks on a massively loaded SQL Server. There are times that you may not care that your data isn’t exactly 100% committed and you need results back quickly even though they may be out of date.
Ask yourself a question when thinking of using NOLOCK
:
Does my query include a table that has a high number of
INSERT
/UPDATE
commands and do I care if the data returned from a query may be missing these changes at a given moment?
If the answer is no, then use NOLOCK
to improve performance.
I just performed a quick search for the NOLOCK
keyword within the code base for Stack Overflow and found 138 instances, so we use it in quite a few places.