mysql - 在 C 中追加或创建文件时如何请求连续 block (非碎片)？

Question

所以我想了解 DBMS 实现是如何工作的

举个例子:

MySQL用自己的页面实现每个表，页面大小为16KB

因此每个表都是一个文件，并且是 16KB 的倍数，考虑到它有多大以及因此需要多少页

现在我在某处读到，这些页面不会在磁盘镜像或内存镜像中碎片化，所以我的问题是，如何？

DBMS 开发人员如何告诉操作系统“嘿，我刚刚向此文件添加了 16KB 数据(页面)，但使此页面不会变得碎片化”

是因为内存镜像实际上并没有显示字节在磁盘上的实际存储方式及其逻辑吗？

或者是因为这些 DBMS 以某种方式要求操作系统确保这些 16KB 字节的 block 不会出现碎片？

如何在 C 中做到这一点？

Answer 1

50年前，你的问题是计算机科学与工程领域的热门话题。但今天不行。

实际上每个硬盘驱动器都有一个 512 字节的分配单元。 CD 的 AU 为 2KB。某些 SSD 在针对 MySQL 进行调整时，其 AU 为 16KB。

有许多不同的“文件系统”。 Windows(至少)有 FAT-32 和 NTFS。 *nix 有很多。每个 FS 都以在某件事上做得更好而自豪。但可用空间管理与分配单元大小有关。还记得当磁盘变得越来越大时 DOS 使用 FAT-16 时遇到的麻烦吗？名称中的“16”是指磁盘最多具有 2^16 个 block 。这迫使 2GB 磁盘驱动器的分配单元为 32KB!典型的系统有很多小文件，实际上一半的磁盘可能被浪费了!

我正在谈论“分配单元”，因为这本质上是防止操作系统考虑将 block 分散在驱动器周围的唯一方法。

让我们从营销的角度来看看您的问题。如果碎片是如此重要，那么

1. 新的、更好的文件系统将会出现来解决这个问题——尽管不一定是以您提到的简单方式。
2. 操作系统已经知道这个问题，因此它们有“尝试”分块分配的方法。但必要时他们总是愿意给你一些小东西。
3. MySQL 的 InnoDB(大约 2000 年)付出了很大的努力来分配 4MB(？)的“范围”，希望获得连续分配的磁盘。但当它失败时，什么都不会崩溃。
4. 软件可以绕过这个问题，例如使用“原始驱动器访问”。但请注意，它并不位于“如何优化数据库”的最前沿？即使可用，它也会被埋在“哦，通过方式”章节。

几十年前，有一些操作系统可以让您预先分配“连续”的文件。我最近没有听说过这样的事情。

企业系统通过使用带有电池支持写入缓存的硬件 RAID Controller 解决了该问题。不仅分散-聚集对用户隐藏，而且由于崩溃安全缓存，写入变得“即时”。

SSD 没有任何寻道时间(与 HDD 不同)，因此 block 是否被切碎并不重要。当然，有一些代码可以处理它，但与传输、校验和、互斥、系统调用等次数相比，这确实微不足道。

我有一条经验法则:如果一项潜在的优化看起来不会带来 10% 的帮助，我就会放弃它并转向其他事情。我建议你继续前进。