If I have two table of data. One has a clustered index CINDEX, the other is a heap HEAP.
Both also have a non-clustered index on the same column - SEARCHCOL
Assume my clustered index columns are the same size as a rowid and therefore the depth of both of the non-clustered index is the same.
Which would take fewer I/O's to fetch a table row...
a) SELECT * FROM CINDEX WHERE SEARCHCOL = :1
b) SELECT * FROM HEAP WHERE SEARCHCOL = :1
Choose a or b Explain why state any assumptions
If the Searchcol has enough selectivity then the plan should do the expected seek into non-clustered index (identical between the two) and then lookup the clustered index or the heap in order to get all the columns as to satisfy the * projection. This later lookup will be faster in a heap (direct search by page:slot) compared to a BTree seek (has to hit 1-2 non leaf pages to land on the leaf page containing the row) if the heap row was not moved. If the heap row was moved, then the lookup has to chase the forwarding pointer on a new page, meaning a new logical read IO, and so on until it find the place (if it mover multiple times). So in general a heap would save 1-2 logical read IOs (the non-leaf part of the seek in the lookup).
If the SEARCHCOL is not selective enough and the query hits the Tipping Point then all bets are off as one plan would to a clustered index scan in key order, while the other would to a heap scan in allocation order (they would end up roughly the same IO).
But I have to warn that this kind of minutia measurement (1-2 page IOs) are not healthy when making a decision about heap vs. BTree. My take is always choose BTree unless there are explicit reasons not to. Explicit reasons would usually be INSERT performance (this is where HEAPs run circles around BTrees) and that implies ETL data load scenarios where the data is loaded into a heap for fast upload performance and then the heap is turned into a clustered index and added with a switch operaiton into the big fact table.