The NOLOCK compiler hint is sometimes used to help performance of a query that is causing or affected by deadlocks, or slowed down by temporary locks on data it is trying to access.
Using the NOLOCK compiler hint has the identical effect as setting READ UNCOMMITTED except for the scope they affect. Both allow dirty reads. The effect can be a record being missed in the result set of a query, or a record being returned multiple times in a query. This is because the SQL Server engine may be reorganizing records in indices during the dirty read, so as the index is scanned an entry is missed or hit multiple times.
The default SQL Server setting (READ COMMITTED) should give the best performance of all isolation levels that ensure repeatable, "clean" reads.
We do not recommend using NOLOCK as a best practice. We don't recommend using it by default in applications or reports.
Performance problems should be dealt with by optimizing the query and creating indices as necessary. The quicker queries run, the shorter any locks are held which further increases performance and reduces the chance of deadlocks. One helpful habit is to ensure that transaction blocks are as small as possible. Any processing that is not critical to the integrity of the transaction (e.g., looking up related data) should be taken out to reduce its size.