MySQL聚集索引中的磁盘IO

Question

​

​

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

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

Answer 1

如果页面不在InnoDB Buffer Pool的内存中，则InnoDB必须从磁盘获取该页面。

获取后，页面将保留在缓冲池中，除非它被其他页面逐出，或者MySQL服务器进程重新启动。

当页面在缓冲池中时，读取该页面的后续请求将从RAM中读取该页面，而不会引起磁盘IO。

Answer 2

Short answer

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

答:这要看情况。在很多事情上。

Long answer

I/O是查询中最慢的部分。(如果所有东西都被缓存了，那么其他的考虑因素就变成了“最坏的”。)在猜测一个查询需要做多少I/O时，我喜欢做这些简化的假设：

• 扇出是100。也就是说，BTree中的每个非叶节点(数据或索引)下大约有100个节点。在OP的图中，扇出仅为2 --这是在页面上进行调整所必需的简化；100更realistic.
• Only数据的叶节点，需要在计算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索引contain the column(s) of the主键`)。这些列用于向下钻取数据的BTree，以获取其余列。

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

所有块(叶/非叶、数据/索引)被(几乎)同等对待。来自buffer_pool的来来去去(大致)最近最少使用的算法。这使得对I/O进行计数基本上是不可能的。所以，我估计。