Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
No. In SQL Server, using an index does not make NOLOCK safe. The hint gives a query READUNCOMMITTED behavior, so it can read changes that have not been committed and may later be rolled back. Microsoft also warns that a query can return the same record twice or miss records entirely. An index affects how SQL Server accesses data; it does not provide a consistent read.
Why an index does not protect a NOLOCK query
An index is an access path: it organizes data so SQL Server can locate or scan rows. An INDEX(...) table hint can direct the optimizer to use specified indexes. By contrast, NOLOCK controls the read’s locking behavior by giving it the same effect as READUNCOMMITTED. These hints address different things, and choosing an index does not cancel the isolation behavior of NOLOCK. See Microsoft’s current table hints documentation and its SQL Server 2016 table hints reference.
What can go wrong with NOLOCK
Reading data that is rolled back
If another transaction changes a row but has not committed, a NOLOCK query may read that uncommitted value. If the transaction later rolls back, the query has acted on data that never became committed database state.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rows returned twice or not at all
Dirty reads are not the only correctness risk. Microsoft warns that under READUNCOMMITTED, rows can appear more than once or be missed. An index does not guarantee that a query using NOLOCK sees a stable, complete set of rows.
#1 Best Overall
A scan can fail during data movement
SQL Server documents error 601 with the message “Could not continue scan with NOLOCK due to data movement.” It is a possible failure, not an outcome of every scan. Microsoft advises retrying the operation or removing the hint; it also identifies READ COMMITTED or SNAPSHOT as alternatives. See the Microsoft error 601 reference.
NOLOCK does not mean a query can never block
NOLOCK can avoid waits on shared data locks that would otherwise protect a read from concurrent data changes. It does not eliminate all locking. SQL Server still takes schema-stability (Sch-S) locks during compilation and execution, and a query can be blocked by a concurrent schema-modification (Sch-M) lock. So “NOLOCK never blocks” is not accurate.
Safer ways to reduce reader-writer contention
If you need to reduce locking contention without permitting dirty reads, Microsoft documents two options to evaluate: READ COMMITTED with READ_COMMITTED_SNAPSHOT enabled, or SNAPSHOT isolation. Both use row versioning to support reads without the same reader-writer data-lock contention, but they differ in configuration and isolation scope. Consult the Microsoft transaction isolation documentation and confirm the target database’s settings and application transaction requirements before choosing.
- READ COMMITTED with READ_COMMITTED_SNAPSHOT: retains the READ COMMITTED isolation level while using row versions for reads when the database option is enabled.
- SNAPSHOT: uses row-versioned reads at the transaction isolation level; the application must select this isolation level, and database configuration must support it.
Neither is a universal drop-in change: assess the SQL Server version, database options, and the consistency the application needs. The goal is to choose an isolation strategy deliberately—not to rely on an index to make NOLOCK consistent.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
