reduce number of innodb pages read by a query
Short Answer:  It depends.

Let's start by assuming "simple query on secondary key", leads to one row and you have

INDEX(x)
SELECT * FROM t WHERE x = 123


Then, for 600M rows, and a cold cache (buffer_pool), here is the analysis:


Drill down the BTree for INDEX(x) looking for 123:  about 5 blocks need to be read because the BTree will be about 5 levels deep.  The leaf node will give you the primary key column(s) for the one (as assumed) row with x=123.
Drill down the BTree for the PRIMARY KEY and data:  also about 5 blocks.


Total 10 blocks.

Let's expand that to saying that there are 200 rows with x=123.


5 blocks to get started in the index.
Scan forward in the index, perhaps 2 more blocks.  (Rule of Thumb:  100 rows per block.)
For each of the 200 x=123 index entries, drill down the PK to find a row.
The first one (assuming cold cache) needs to read about 5 blocks (as before).
The other 199 will need fewer than 5 blocks.  For one thing, the root node is already there.  Are the x=123 values randomly scattered?  Or is x, say, a TIMESTAMP that marches in sync with the PK (which might be an AUTO_INCREMENT?)  So, these 199 could average as low as nearly 1.


Total:  ~20 to ~600.

Now let's change to steady state:

If your table will fit in cache, then eventually the number of blocks read will be zero.  But, let's say your 600M rows is too big for that.

Again, I invoke a Rule of Thumb:  "Ignore the drilldown, but not the leaf node".


for 1-row:  2 blocks.
for 200 rows:  3+200 blocks -- 3 in the index; 200 (or fewer, depending on randomness of x versus PK) in the data.


Rick's "Rules of Thumb".

Text/Blob

If there are large text or blob columns and you are fetching them, then "off-block" storage will be hit.  This will add perhaps at least 200 more reads -- depending of number/size/existence of the wide columns in each row.