回表查询为什么是随机IO

Question

我看了这个问题的解答：https://segmentfault.com/q/10...
我认为随机索引和顺序索引的关键就是我们知不知道所查的记录和磁盘位置的关系，如果知道，那就是顺序IO，不知道就是随机IO
那么回表查询时我们已经查到所需记录的主键了，根据主键就可以找到对应记录所在的磁盘位置，为什么会是随机IO呢？即使所查的主键不在用一个磁盘页，也应该是顺序IO吧

Answer 1

“我认为随机索引和顺序索引的关键就是我们知不知道所查的记录和磁盘位置的关系，如果知道，那就是顺序IO，不知道就是随机IO” —— 错误 ❌

你对顺序 IO 和随机 IO 的概念理解完全错误 ❌

当要读取的东西紧紧诶在一起，就是顺序IO，反之就是随机 IO

硬盘 DB 多是 B+ 树，以页为单位。而页在硬盘的位置是随机的，所以当要读取两个页的时候，99.99%是随机 IO

回表这个概念必然是相对两个独立的页的，所以几乎必然是随机 IO

---

以 mysql Innodb 为例子，一个页的大小是 16KB，页是随机分布式在硬盘上的，当需要跨页的时候，机械硬盘的磁头就需要重新定位。（固态虽然没有磁头，但是你可以假设有），读取这个 16 KB是顺序读的，但是要读取下一个页，有可能是紧挨着这个页的，也可能隔了好几个磁道，这个是数据库不保证的。

因为这个页不大不小，你需要的数据往往做不到在一个页就有结果，往往一个 curd 操作，这个磁头就需要 n 次定位操作，所以想 mysql 的 curd 我们往往认为随机性比较强。

以 Hbase 为例子，hbase 的 “页” 是 64MB，相比 mysql 大了 4000 倍，所以我们认为 hbase 的顺序性比 mysql 强。

hbase 使用的叫做 lsm 树，这个数据结构的特点就是最大化的利用硬盘的顺序读写能力远远大于随机读写速度的特点来做的，可以参考：深入浅出分析LSM树（日志结构合并树）