I have a query app scanning a whole table with a text field.
The query is doing this many reads:
Scan count 1, logical reads 170586, physical reads 3, read-ahead reads 174716, lob logical reads 7902578, lob physical reads 8743, lob read-ahead reads 0.
Query plan with lob logical reads
If I remove the text field from the select, reads become the following:
Scan count 1, logical reads 170588, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Query plan without lob logical reads
The thing that I don't get is how lob reads works:
if I sum up the logical reads with lob logical reads I get a total of 8.073.164 logical reads, which, if I'm correct, is about 64GB.
But the entire database is only 7GB!
I'm probably missing something about adding up logical reads and lob logical reads.
What does the number of lob logical reads actually represent?
SELECT
with just a clustered index scan is still worth sharing the actual execution plan for which contains a lot of runtime information encoded in it besides just the operators. But I agree with Tibor that your query is probably resulting in the same data pages to be read multiple times, compounding the amount of data being read off disk.ActualLobLogicalReads
is0
in both of those plans