The WITH (nolock) hint is an explicit command directed at a specific table or view used to set the transaction isolation level against the table or tables within a view for a specific query. Once issued, locks will not be used against the data within the table. The advantage to this is there is no chance a deadlock will occur against any other queries running against the table. The other indirect advantage is that less memory will be used in order to hold locks against that data.
Example:
first_name,
last_name,
FROM dbo.person p WITH (NOLOCK)
JOIN dbo.employee e WITH (NOLOCK)
ON e.person_id = p.person_id
WHERE p.person_id = 1;
The nolock setting above is explicit for the table it is being set against. To set the value globally for the scope of the connection, see SET TRANSACTION ISOLATION LEVEL
Clik here to view.
Advantages:
- Deadlocks will not occur against other queries running against the same data
- Less memory is utilized due to the lack of row, page, or range level locking
- Typically allows for much higher concurrency due to lower footprint
Disadvantages:
- Uncommitted data can be read leading to dirty reads
- Explicit hints against a table are generally bad practice
Usage
In most places I have worked, with (nolock) has been a generally accepted practice only in specific areas of the system that are not sensitive to data being slightly out of sync. It is important to know where things could go wrong though. The biggest example I can think of is in a system that uses explicit transactions (BEGIN TRAN ..END TRAN) or heavy use of triggers. Multiple statements executed within a transaction experience a time delay of their INSERT / UPDATE / DELETE operations however the changes are committed at once upon the COMMIT. Statements that query the changed data using the READ COMMITTED isolation level will be blocked from seeing these changes until commit, whereas READ UNCOMMITTED (NOLOCK) will see the changes immediately irregardless of when the commit occurs. The assumption here is that if your system uses explicit transactions or relies on triggers heavily, it may be plausible to assume nolock is not a good idea.
Clik here to view.
Example of a Dirty Read
The following example will open a transaction in order to update the first_name column in our global temp table: ##my_name
BEGIN
DROP TABLE ##my_name;
END;
CREATE TABLE ##my_name
(
id INT,
first_name VARCHAR(20)
);
INSERT INTO ##my_name (id, first_name)
VALUES (1, 'dexter');
BEGIN TRAN
UPDATE ##my_name
SET first_name = 'derek'
WHERE id = 1;
Here we have left a transaction open on ##my_name so that row is exclusively locked and cannot be read by any transaction using isolation level read committed or higher.
Open a new connection and execute the following queries:
SELECT * FROM ##my_name;
Here you will see the first query will show the updated value ‘derek’, whereas the query without the nolock will hang waiting for the transaction to release. The data that has been successfully read is considered dirty data. This is because there may be other tables that need to be updated which relate to the ‘derek’ record (id=1) in order to show a consistent view of all data related to ‘derek’.
Finally let’s commit our transaction within our original window and you’ll see that you are now able to query the data without using (nolock).
SELECT * FROM ##my_name;