MySQL 8 InnoDB 32KB 和 64KB 页面大小对 HDD 的好处

Question

MySQL page size documentation说:

For releases up to and including MySQL 5.5, the size of each InnoDB page is fixed at 16 kilobytes. This value represents a balance: large enough to hold the data for most rows, yet small enough to minimize the performance overhead of transferring unneeded data to memory. Other values are not tested or supported.

Starting in MySQL 5.6, the page size for an InnoDB instance can be either 4KB, 8KB, or 16KB, controlled by the innodb_page_size configuration option. As of MySQL 5.7.6, InnoDB also supports 32KB and 64KB page sizes. For 32KB and 64KB page sizes, ROW_FORMAT=COMPRESSED is not supported and the maximum record size is 16KB.

然后

Smaller page sizes can help performance with storage devices that use small block sizes, particularly for SSD devices in disk-bound workloads, such as for OLTP applications. As individual rows are updated, less data is copied into memory, written to disk, reorganized, locked, and so on.

使用比默认 16KB 更大的页面大小(32KB 或 64KB)怎么样？ 在什么情况下你应该这样做以及你能得到什么好处？

我将使用传统 HDD 设置一个新的 MySQL 实例，我想知道更改默认 16KB 是否会对性能和存储利用率产生影响。

到目前为止我只发现使用 32KB 和 64KB 页面大小的缺点:

For 32KB and 64KB page sizes, ROW_FORMAT=COMPRESSED is not supported and the maximum record size is 16KB.

Answer 1

有些人的最大行大小约为 8000 字节。切换到 32KB 页面会使该限制加倍。但是，切换到 64KB 不会超过 16KB 限制。

由于 InnoDB block 往往分散在磁盘周围，因此拥有更大的 block 将稍微节省 HDD 上的机械臂运动。我预计这只会个位数的百分比改进。它会根据事件的类型而有所不同。刚加载的表可能没有任何改善；一个有很多流失的表可能会显示一些。

如果您的数据集适合buffer_pool，则无需执行太多 I/O，因此 block 大小不会发挥太大作用。

通过优化磁盘操作顺序的驱动程序或 Controller ，可以在一定程度上最小化 ARM 运动的成本。带有缓存的 RAID 做得特别好，它几乎可以即时写入。 “打洞”可能会增加 ARM 运动的频率。经典权衡:“速度与空间”。

如果您的数据集太大而无法容纳在 RAM 中，并且如果您执行大量“点查询”，那么较小的 block 大小会更好。但如果您进行大量表(或索引)扫描，则较大的 block 大小会带来一些好处。

请记住，所有数据必须使用相同的 block 大小。

在我见过的数千个论坛问题中，我认为没有任何问题改变了 block 大小。您将进入未知领域。

另请注意，虽然 ROW_FORMAT=COMPRESSED 节省了一些磁盘空间，但它占用了一些 RAM - 这是因为一些(全部？) block 保存在 RAM 中压缩和未压缩。

我看到的 row_format 的数字只有 50%。任何合适的压缩算法实际上都可以将任何类型的文本压缩大约 2/3。因此，如果我想使用压缩，我会压缩可压缩列(例如 TEXT，但不是 jpg)，并在客户端中执行此操作，从而减轻 CPU 负担从服务器。我相信(没有任何确凿的证据)这是压缩数据的更好的方式。另外，我几乎从不使用 BIGINT。

(我在这里所说的一切都是理论，基于非常有限的 MySQL 文档或 HDD 原理。)

我有一个优化的经验法则。 “如果粗略计算估计改进不到 10%，那么就继续寻找其他东西来优化。”

所以，我说“继续前进”。