Logical Reads vs. Records Returned I have a very basic query against a large table that roughly follows this form:

SELECT
    [Extent1].[A] AS [A],
    [Extent1].[B] AS [B]
FROM [dbo].[SomeTable] AS [Extent1]
WHERE
    ([Extent1].[A] &lt;= (SysUtcDateTime()))
    AND (2 = [Extent1].[B])


This query spends 100% of its time using the clustered index. In different environments I have observed these results:


DEV: 391 rows, 12 logical reads
QA: 341502 rows, 6030 logical reads
UAT: 1273656 rows, 52536 logical reads


It seems to me that this query is about as efficient as it can be given the size of the result set.

Is there a generally accepted correlation between logical reads and the amount of data returned by a query? If so, is it safe to say that these results fall within that acceptance range for a well-performing query?
Is there a generally accepted correlation between logical reads and the amount of data returned by a query?
  


The missing piece is the

1) The number of logical reads of pages with no relevant data

2) The number of relevant result rows on each page

And these two are determined by your indexes.  If this table has no relevant indexes, then you will have to scan each page, and you will have to read a lot of completely or mostly irrelevant pages.  Even if your index supports a query plan where you read only pages (mostly) full of relevant rows, if those rows are very wide, then there may not be very many (A,B) pairs per page.

If you had an index on (B,A) on this table then SQL could seek to the first row where B=1 and start scanning rows until it hits a row with A>SysUtcDateTime().  This would only require ~4 Logical IOs to get to the first page, and then every Logical IO would result in ~700 (A,B) pairs.