Seek time on a spinning disk is a few milliseconds -- a combination of the arm motion and the rotational delay waiting for the sector(s) to come under the read head.
- arm motion (a few ms).
- 10K RPM (rotations per minute) = 667/sec --> 1.6 ms. Consider half that for the average delay.
- fetch the sectors. One sector is 512 bytes; 32 sectors needed for an InnoDB 16KB block. (Timing depends on how many sectors per track.)
- Checksum and transfer to RAM
- Poke around in the block to find the row(s) desired.
- Work with the rows.
10ms is a simple, and often accurate enough, Rule of Thumb for the total time to read 1 block.
The 100MB/1s is probably predicated on optimal conditions of streaming consecutive sectors from each track, and hitting consecutive tracks -- thereby eliminating the first 2 steps in my list. These are often the most costly two.
SSDs replace the first 2 steps by a much faster random fetch.
Yes, all row actions in MyISAM's InnoDB involve first having the desired 16KB block(s) sitting in the buffer_pool (in RAM). Blocks will be fetched as needed, not pre-fetched, so don't expect the benefits of "streaming". Also, most tables are not laid out on disk consecutively, so there will be frequent arm and/or rotational delays. InnoDB is more optimized for efficiency when handling multiple threads than for speed of a single thread.