当元素大小不同时如何维护 B-tree 不变量？

Question

对于 m 阶 B 树，除根外的每个节点都必须包含 m-1 到 2m-1 个元素，其中每个元素至少是一个键，也可能是一些附加数据（例如，一个值）。然而，每个节点必须选择一些恒定的总大小才能在底层块设备上提供良好的性能。那么如果你的元素是可变大小的会发生什么呢？

SQLite3 似乎有一个将额外的块大小的片段附加到其节点上的方案，并且 MySQL 允许您声明记录的大小（例如，您可以键入字段不仅是字符串，还可以是某种大小的字符串）。还有哪些其他解决方案？人们在选择其中一个时会考虑什么？

edit：上一句，我的意思是，数据库开发人员在决定实施他们的 B 树时会考虑什么远超其他？

（我现在正在上数据库课程，所以我对理论和设计角度更感兴趣，而不是特定系统的细节。）

Answer 1

我知道 SQL Server 在页面大小为 8192 字节的情况下，密钥长度最多可达 900 字节。如果您实际上有 900 字节的键，则只有 9（或 8）行将适合索引的中间级页面。这只是意味着分支因子比平时低。这可能违反了理论上的 B-tree 不变量，但这只是一个学术问题，不会显着阻碍性能。它不会改变所涉及算法的渐近复杂度。

简而言之：这纯粹是学术问题。

Answer 2

我认为这是一个很好的问题。尽管 RDBMS 供应商的实现略有不同，但基本理论是相同的，我怀疑是否有人使用 b-tree 实现作为选择供应商的决定因素。

据我了解，每个 b-tree 页面的基本结构都包含键和指针。指针不断引用包含更多键和指针的其他页面，最终指针引用关联的数据记录。

如何处理可变长度键很有趣。也许其他人可以对供应商特定的解决方案有所了解。