MySQL群集索引中的磁盘IO

Question

我了解到mysql中聚集索引的叶节点存储行数据。

如果从聚簇索引中检索数据，则不会发生物理磁盘IO吗？

Answer 1

如果InnoDB还没有从InnoDB Buffer Pool的RAM中提取页面，则必须从磁盘中获取页面。

一旦获取，除非其他页面驱逐了该页面，否则页面将保留在缓冲池中，否则MySQL Server进程将重新启动。

虽然页面位于缓冲池中，但随后的读取该页面的请求却是从RAM中读取的，而不是从磁盘IO上获取的。

Answer 2

简短答案

问：如果从聚集索引中检索数据，是否不会发生物理磁盘IO？

A：要视情况而定。在很多事情上。

好答案

I / O是查询中最慢的部分。 （如果所有内容都已缓存，则其他考虑因素将成为“最糟糕的情况”。）在估算查询需要执行多少I / O时，我希望做出以下简化假设：

• 扇出为100。也就是说，BTree（数据或索引）中的每个非叶节点下面都有大约100个节点。在OP的图表中，扇出仅2个，这是简化页面尺寸的必要简化； 100是更现实的。

• 在对I / O进行计数时，仅需要对数据的叶节点进行计数。在很多情况下，这是一个过度简化的例子，但是在运行平稳的生产系统中，这是相当不错的。

这两个简化避免了已经指出的血腥细节。考虑一下-非叶数据节点可能占BTree节点的1％，因此生产系统很可能会到达所有它们都被缓存的位置。

“点查询”可能需要I / O。 “范围查询”可能需要每读取100行读取一个块。请注意，您永远不会使用UUID进行“范围查询”。

在InnoDB中，一个INDEX（包括UNIQUE) is very much like a clustered index, with the exception of what is in the leaf nodes. The "rows" of an INDEX contain the column(s) of the PRIMARY KEY。这些列用于向下钻取数据的BTree以获得其余的列。

“使用索引”表示“覆盖索引”，这意味着SELECT所需的所有列 在INDEX's BTree中找到。在这种情况下，可以避免反弹到数据BTree。

所有块（叶子/非叶子，数据/索引）都被（几乎）相同地对待。从buffer_pool来来去去（大约）是最近最少使用的算法。这使得I / O的计数基本上是不可能的。所以，我估计。