数据库索引实现疑问：为什么磁盘块不能存储多个索引树节点？

你提出的blockNumber + offset寻址、单磁盘块存储多个索引节点的方案技术上是完全可实现的，目前主流数据库没有普遍采用这种设计，核心有几点原因：

• 适配磁盘IO的最小读写粒度
  磁盘、文件系统的最小读写单元就是磁盘块（通常为4KB~16KB），哪怕仅需要读取块内一个小尺寸的索引节点，也要完整读取整个块的数据。如果单块存储多个节点，每次读取目标节点都会额外加载同块内无关的节点数据，浪费IO带宽；写入时修改单个节点也需要回写整个块，会额外提升写放大。
• 简化B+树核心操作的实现逻辑
  B+树的核心运行逻辑就是节点的分裂、合并，如果单块内存储多个节点，需要额外实现块内空间的动态分配、碎片整理、节点扩容缩容的块内调度逻辑，代码复杂度会成倍提升，还会引入很多不可控的性能波动，收益远低于成本。
• 树高优化的收益已经达到瓶颈
  单块对应单节点的设计，核心目标就是尽可能提升单个节点的键存储数量、降低树高从而减少IO次数。以常见的16KB块、8字节整型主键为例，单个B+树非叶子节点可存储近千个索引键，3层树高即可支持千万级数据的寻址，IO次数已经压缩到极低水平。调整为单块多节点的设计最多只能降低零点几层树高，带来的收益完全覆盖不了额外开销。
• 适配数据库缓冲池的管理逻辑
  数据库的缓冲池默认以磁盘块为单位进行缓存、淘汰管理，如果单块存储多个节点，无法单独淘汰块内长期不访问的节点，反而会降低缓存命中率，影响整体性能。

内容的提问来源于stack exchange，提问作者rwxe