数据库的数据为什么抽象成page和block

将数据库中的数据抽象成页（Page）和块（Block）作为基本的数据管理和 I/O 单位，最根本的驱动力是为了克服磁盘 I/O 的性能瓶颈

将数据库中的数据抽象成页（Page）和块（Block）作为基本的数据管理和 I/O 单位，是数据库系统设计中的一个核心概念，其背后有多方面的原因，但最根本的驱动力是为了克服磁盘 I/O 的性能瓶颈。我们可以从以下几个关键角度来理解：

机械硬盘 (HDD): 传统硬盘读取数据最耗时的部分是寻道时间 (Seek Time)（移动磁头到正确磁道）和旋转延迟 (Rotational Latency)（等待数据块旋转到磁头下方）。一旦磁头就位，连续读取一块数据的速度相对较快。
固态硬盘 (SSD): 虽然 SSD 没有机械部件，寻道时间和旋转延迟几乎为零，但它仍然存在访问延迟，并且其内部也是以块（通常比操作系统页面大）为单位进行擦写操作的。
结论: 无论是 HDD 还是 SSD，执行一次 I/O 操作本身的开销（定位、启动）远大于传输少量数据的开销。因此，一次性读取或写入一个较大的数据块（比如 8KB 或 16KB），比多次读取或写入许多小的字节或记录要高效得多。 页面/块的作用: 通过将数据组织成固定大小的页面/块（例如 4KB, 8KB, 16KB），数据库可以将多次小的逻辑 I/O 请求合并成一次大的物理 I/O 请求。这摊销 (Amortize) 了每次 I/O 的昂贵开销，极大地提高了整体吞吐量。这就好比你去超市购物，一次买回一周的必需品，比每天都跑一趟要省时省力。

数据库为了减少昂贵的磁盘 I/O，会在内存中开辟一块区域叫做缓冲池 (Buffer Pool)，用来缓存从磁盘读来的页面。

管理简化: 当缓冲池被划分为一个个固定大小的页面槽 (Frame) 时，管理起来就非常方便。可以轻松地维护哪些页面在内存中、哪些页面是“脏”的（被修改过需要写回磁盘）、哪些页面可以被替换出去。
替换算法: 像LRU(Least Recently Used)、Clock 等经典的页面替换算法都是基于固定大小的页面来设计的。如果处理的是大小不一的数据单元，管理会变得极其复杂和低效。
内存分配: 固定大小的页面使得内存分配和回收变得简单、快速，并能有效减少内存碎片。

很多数据库内部核心的数据结构，尤其是索引结构（如 B+ 树），都是围绕页面/块来设计的。

B+ 树: B+ 树的每个节点（无论是内部节点还是叶子节点）通常都被设计成恰好能容纳在一个或多个页面中。这样做的好处是：
- 减少 I/O 次数: 访问 B+ 树时，从根节点到叶子节点，理想情况下每深入一层只需要一次磁盘 I/O（如果节点不在缓冲池中）。
- 提高扇出 (Fan-out): 页面大小决定了 B+ 树内部节点能容纳多少个键和指针，这直接影响树的“扇出”。较大的扇出意味着树的高度较低，从而进一步减少查询所需的 I/O 次数。
- 顺序访问: 叶子节点通常通过指针链接在一起，这使得范围查询可以高效地进行顺序 I/O。

操作系统: 操作系统自身也使用页面 (Page) 来管理虚拟内存和物理内存。
文件系统: 文件系统则使用块 (Block) 来组织磁盘上的数据。
对齐的好处: 数据库的页面大小通常设置为操作系统页面大小或文件系统块大小的整数倍。这样做可以：
- 减少 I/O 路径上的复杂性: 使得数据库的 I/O 请求能更直接地映射到底层系统的操作。
- 利用 OS 缓存: 更好地与操作系统的文件缓存协同工作（虽然数据库通常倾向于自己管理缓存以获得更精细的控制）。
- 直接 I/O (Direct I/O): 在某些情况下，允许数据库绕过 OS 缓存，直接读写磁盘，这需要对齐。

锁粒度: 虽然现代数据库倾向于更细粒度的锁（如行锁），但页面锁仍然是一种可选的、实现相对简单的锁粒度。
日志记录: 数据库的恢复日志（如 ARIES 算法）通常记录的是对页面的修改。恢复过程也常常涉及读取日志并将页面恢复到一致的状态。以页面为单位进行日志记录和恢复操作，简化了设计。

通常情况下：

块 (Block): 更偏向于指代磁盘上的物理存储单位，是文件系统和 I/O 子系统打交道的单位。
页 (Page): 更偏向于指代内存（尤其是缓冲池）中的逻辑管理单位。但在数据库的语境下，这两个词经常被混用，通常指代的是同一个概念：数据库系统进行 I/O 和内存管理的固定大小的基本单元，它们的大小一般是相同的。

总结: 将数据抽象成页面/块，是数据库系统为了在昂贵的磁盘 I/O 和 高效的内存管理 之间取得平衡而做出的关键设计决策。它是一种抽象层，屏蔽了底层硬件的复杂性，并为上层的数据结构、查询处理、并发恢复等模块提供了一个简洁、高效的基础。

📎 参考文章#