Logical reads are the number of 8 KB data pages SQL Server reads from the buffer pool to satisfy a query — the most reliable, hardware-independent measure of how much work a query does.
You reduce them by helping SQL Server touch fewer pages: better indexes, SARGable predicates, selecting only the columns you need, current statistics, and set-based logic instead of row-by-row processing.
If you optimize for one number, make it logical reads. Duration lies — it swings with load and caching — but logical reads count the actual work and stay stable run to run. This guide shows how to measure and lower them.
What logical reads are — and why they matter
SQL Server stores data in 8 KB pages. A logical read is one page read from the buffer pool (memory); a physical read is a page that had to come from disk first because it was not already cached. Because logical reads ignore whether a page happened to be cached and ignore disk speed, they are the most repeatable signal of query cost.
Measure them with SET STATISTICS IO ON; before a query — SQL Server then prints logical, physical, and read-ahead reads per table. Compare the logical-read count before and after a change to prove the optimization worked.
Proven ways to reduce logical reads
Index so SQL Server seeks, not scans
Indexing is the highest-leverage lever. A selective index turns a full scan into a seek that touches a handful of pages; a covering index (the right key columns plus INCLUDEd columns) lets a query be answered entirely from the index and eliminates key lookups. Fewer, narrower pages mean fewer logical reads.
Write SARGable predicates
A predicate is SARGable when an index can satisfy it. Wrapping a column in a function (WHERE YEAR(OrderDate) = 2026) or comparing mismatched types forces SQL Server to read and evaluate every row. Rewriting to a range — WHERE OrderDate >= '2026-01-01' AND OrderDate < '2027-01-01' — restores the seek and cuts reads dramatically.
Select only the columns you need
SELECT * pulls every column, inflating the data read and defeating covering indexes. Per Redgate's guidance, selecting only the necessary columns reduces the data SQL Server must read and lets narrower indexes cover the query.
Keep statistics current
The optimizer uses statistics to estimate row counts. When they are stale, it underestimates and may pick a plan that reads far more pages than necessary. Current statistics keep the optimizer's plan choices — and the resulting reads — sensible.
Prefer set-based logic; fix fragmentation
- Set-based over row-by-row. Cursors and
WHILEloops re-read pages repeatedly; the equivalent set-based statement reads them once. - Fragmentation lowers page density, so SQL Server reads more pages to get the same rows. Reorganizing or rebuilding fragmented indexes restores density.
Always re-measure with SET STATISTICS IO ON after a change. A rewrite that lowers logical reads is a real win; one that does not is just a different query.
Connect it to the bigger picture
Logical reads are one of the three costs (alongside duration and CPU) that the stored procedure optimization loop tracks. The cause of high reads usually shows up plainly in the execution plan — a scan, a key lookup, or an estimate that is far off.
SprocOptimizer captures logical reads as part of its before/after measurement, so any rewrite it proposes is judged on whether it genuinely reduced the work — not just on a duration number that can move for unrelated reasons.
Frequently asked questions
Logical reads are the number of 8 KB data pages SQL Server reads from the buffer pool (memory) to satisfy a query. A physical read happens when a page is not already in memory and must be read from disk first; once cached, subsequent access to that page counts as a logical read. Logical reads are the most reliable measure of query work because they do not depend on what happens to be cached or on disk speed.
Run SET STATISTICS IO ON before your query. SQL Server then reports, per table, the number of logical reads, physical reads, and read-ahead reads the query performed. Comparing logical reads before and after a change is the clearest way to prove a query optimization actually reduced work.
Duration varies with server load, blocking, and whether data is already cached, so the same query can be fast one run and slow the next. Logical reads count the pages touched and stay stable across runs, which makes them a far more repeatable measure of whether a change genuinely reduced the work a query does.
Help SQL Server touch fewer pages: add covering or more selective indexes to turn scans into seeks and eliminate key lookups; write SARGable predicates so indexes can be used; select only the columns you need instead of SELECT *; keep statistics current so the optimizer estimates correctly; use set-based logic instead of row-by-row cursors; and address index fragmentation that lowers page density.
Primary sources & further reading
- Redgate Simple Talk — Query tuning with STATISTICS IO and execution plans.
- Bert Wagner — Reducing the number of reads in your queries.
- Microsoft Learn — SET STATISTICS IO (Transact-SQL).
Measure the work, not just the clock
SprocOptimizer captures logical reads in its before/after comparison, so every optimization is judged on real reduced work — on-premises, with no row-level data leaving your network.
Request a Demo Read the Optimization Guide