【问题标题】:Heap vs Clustered index full table scan堆与聚集索引全表扫描
【发布时间】:2021-04-22 04:00:21
【问题描述】:

我一直在谷歌上来回搜索,但无法掌握磁盘上的表数据块的结构。

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

堆不规定顺序,这是因为数据库不关心它从磁盘读取的块的顺序,但是:

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

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

【问题讨论】:

  • 您问的是mysql 还是oracle?这是 RDBMS 的两种不同实现。最佳答案取决于您要问的是哪一个。
  • 我实际上认为这两个会使用相同的原理,但让我们说 MySQL :) @BillKarwin

标签: mysql oracle rdbms clustered-index full-table-scan


【解决方案1】:

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

InnoDB 不将表存储为堆。

InnoDB 表始终存储为聚集索引,其中聚集索引是主键。因此,表扫描或多或少等同于聚集索引的索引扫描。

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

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

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

所以在 MySQL 的情况下:

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

【讨论】:

  • 谢谢比尔。这很有帮助。其他引擎(不是 MySql)是否按顺序存储数据?使用聚集索引时它是如何工作的?
  • 我对其他引擎并不熟悉,但我认为他们不熟悉。顺序存储数据有什么好处?至少在 OLTP 数据库中,应该避免表扫描。为他们优化没有抓住重点。顺序存储也会使在表中间进行更新/插入的成本大大更高,因为单行更新需要从该点重写整个表。跨度>
  • 另外,聚集索引是查找的优化,而不是表扫描。我不希望聚集索引与顺序存储一起使用。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-01-27
  • 2019-08-26
  • 1970-01-01
  • 2010-09-06
  • 1970-01-01
  • 2018-06-18
相关资源
最近更新 更多