为什么默认情况下MySQL聚集索引页大小为16k？

Question

如果MySQL聚集索引所使用的B+树结构的全部思想是有效地访问磁盘数据的话。然后，使索引页大小与通常为512字节的磁盘块大小相等是合乎逻辑的。

然后，一个物理磁盘查找(所需的旋转和其他移动)将为我们提供一个索引页数据。那么，为什么索引页的大小更像16k呢？(据我理解，检索这样的页面需要读取不同的磁盘块，而不是总是顺序的，并且需要进行大量的磁盘旋转)。

我在这里错过了什么？

Answer 1

InnoDB充满了速度和空间之间的妥协。

InnoDB是在SSD之前设计的，所以读取多个相邻的磁盘扇区是个好主意，特别是如果您可能需要的不仅仅是16 so块中的一个。

如果查看整个数据库的磁盘使用情况，在测量空间时，可能会发现“浪费”了几个百分点。

而且，今天，大多数应用程序都很小，可以完全安装在RAM中。所以，块的大小没有什么不同。实际上，由于I/O较少，即使对于SSD，16 Os块在初始负载上也会稍微快一些。

如果您有一个庞大的数据集，并且是I/O绑定的，那么如果大多数情况下对一个小行进行随机读取，您可能会遇到性能困难。示例: ids具有UUID的键值数据集。在这个用例中，SSD上较小的块大小可能要快得多。

回到权衡-- UUID (等等)的例子并不常见。

Answer 2

InnoDB要求至少有两行适合于给定的页面。由于可变长度的数据类型VARCHAR、VARBINARY、TEXT和BLOB可能溢出到其他页面，所以这条规则有点弯曲。否则，给定的行必须小于8KB。

如果InnoDB页面大小小于当前默认的16 is，则行的大小限制将低于当前的大小限制。实际上，您可以重新配置InnoDB以使用不同的页面大小.，这确实改变了最大行大小。

在大多数情况下，默认的16 is被认为是合适的。确实，它可能与磁盘扇区大小不一致，但希望在性能至关重要时，从缓冲池读取查询，而不是从磁盘读取查询。

Answer 3

要检索这样的页面，需要读取不同的磁盘块，而不是总是连续的，并且需要进行大量的磁盘旋转。

这是不正确的。页面是数据库I/O的单位；DBMS一次至少会读取和写入至少一个页面，可能会更多(即多个页面)，尤其是在读取时。这意味着页面在媒体上总是连续的(除非在物理驱动器级别重新定位)。

使索引页大小与通常为512字节的磁盘块大小相等是合乎逻辑的

这也有点不正确。在选择页面大小时，需要在大顺序I/O操作的效率和浪费带宽之间找到一个甜蜜的点，因为您只需要从读取的内容中获取一小部分数据。还有另一个限制:索引键不能跨越页面，因此索引页大小(减去开销)必须能够容纳至少两个键值；从这个角度来看，512字节页是不实用的。

一些DBMSes允许DBA为不同的表和索引选择不同的页面大小，从而能够更精确地调优特定场景的I/O性能。

请参见这与问答有些关联 --它不是关于MySQL的，而是显示了页面大小选择背后的一些推理。