Logical reads and LOB logical reads

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?

Here's my theory,

These are logical reads, not physical reads. Imagine two rows, where the LOB data for these rows is on the same page (yes, pages can be shared across rows for LOB data).

Perhaps each read only reads, say, 100 bytes. Each read is still a logical read.

Furthermore, you say that these are text data type, for which the default is to not have the LOB data in-row. If the type instead were varbinary(max), then the default is to have LOB data in-row (as long as it fits on the page). This can make a big difference, what is best depends on whether you frequently need the LOB data or not. You can reconfigure this (for both types) using sp_tableoption.

StackExchange Database Administrators Q#315456, answer score: 5