堆与聚集索引全表扫描

问题描述

为此我一直在谷歌上搜索,无法理解磁盘上的表数据块是如何构建的。

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

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

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

任何描述块如何在磁盘上布局在每种情况下的资源都会有所帮助

解决方法

您询问了 MySQL,通常指的是 InnoDB 存储引擎,这是默认设置。

InnoDB 不会将表存储为堆。

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

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

为了便于浏览所有页面,每个页面都包含指向下一页和上一页位置的链接。这些可能在文件中很远,因此表扫描实际上不是顺序的,它会涉及对文件中其他位置的多次查找。

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

所以在 MySQL 的情况下:

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

相关问答

Selenium Web驱动程序和Java。元素在(x,y)点处不可单击。其...
Python-如何使用点“。” 访问字典成员?
Java 字符串是不可变的。到底是什么意思?
Java中的“ final”关键字如何工作?(我仍然可以修改对象。...
“loop:”在Java代码中。这是什么,为什么要编译?
java.lang.ClassNotFoundException:sun.jdbc.odbc.JdbcOdbc...