Heap vs Clustered索引全表扫描



我一直在反复搜索这个问题,但无法掌握磁盘上表数据块的结构。

许多资源表明,执行全表扫描是顺序读取块的(这意味着DB能够一次读取多个块),但是我找不到任何资源实际描述在堆和聚集索引的情况下块是如何保存在磁盘上的。

堆不决定顺序,这是因为DB不关心它从磁盘读取的块的顺序,但是:

  1. 我仍然没有找到任何证据保证堆数据顺序存储在磁盘上
  2. 对于聚类索引,结果的顺序很重要。在这种情况下,我无法理解DB如何在保持顺序的同时保持块顺序。对于聚集索引,顺序读取是否仍然有效?

任何描述在每种情况下块如何在磁盘上布局的资源

你问的是MySQL,一般是指InnoDB存储引擎,这是默认的。

InnoDB不以堆的形式存储表

InnoDB表总是作为聚集索引存储,聚集索引是主键。因此,表扫描或多或少相当于聚集索引的索引扫描。

InnoDB中的索引通常不是顺序存储在磁盘上的。它被存储为页的集合,页的统一大小为16KB。索引显然比这个大得多,随着时间的推移,插入和更新会扩展索引的中间部分和末尾部分。为了有效地做到这一点(也就是说,不需要重写整个表),随机插入和更新会导致页面乱序。新创建的页面被放置在文件中有空间的地方。

为了方便浏览所有页面,每页都包含到下一页和前一页位置的链接。这些表可能在文件中相当远的地方,因此表扫描实际上不是顺序的,它将涉及到文件中其他位置的多次查找。

InnoDB要求页面加载到RAM中,然后才能在查询中实际使用它们。InnoDB缓冲池是一个固定大小的RAM分配,其中包含一组从磁盘加载的页面。一旦页面进入缓冲池,就可以非常快速地访问它们,并且几乎没有后续链接的开销。从磁盘读取页面到缓冲池的开销要比在RAM中读取页面的开销大得多。

对于MySQL:

  • 没有堆
  • 聚集索引的顺序顺序与磁盘上的顺序存储无关
  • 无论如何都要对RAM中的页面进行读取,因此磁盘上的物理布局与读取页面的顺序几乎没有关系

最新更新