索引数据输入的备选方案 1

Question

作为数据条目存储在索引中的三个备选方案之一是数据条目 k*，它是具有搜索键值 k 的实际记录。我的问题是，如果您要将实际记录存储在索引中，那么创建索引的意义何在？

Answer 1

这是一个极端情况，因为它并不真正对应 具有由数据记录分隔的数据条目（散列文件是 这种情况的例子）。

（M. Lenzerini，R. Rosati，Database Management Systems: Access file manager and query evaluation，“La Sapienza”罗马大学，2016 年）

备选方案 1 通常用于直接索引，例如在 B 树和哈希索引中（另请参阅 Oracle，Building Domain Indexes）

---

让我们做一个具体的例子。

我们有一个关系R(a,b,c)，我们有一个clustered B⁺⁠-⁠树，在搜索键a 上使用替代2。由于树是聚类的，关系R必须按a排序。

现在，假设关系的常见查询是：

SELECT *
FROM R
WHERE b > 25

所以我们想建立另一个索引来有效地支持这种查询。

案例 1：带有 alt 的聚类树。 2

我们知道 clustered B⁺⁠-⁠具有备选 2 的树对于范围查询很有效，因为它们只需要搜索第一个好的结果（比如一个与b=25），然后对该结果指向的关系页面进行1页访问，最后扫描该页面（最终扫描其他一些页面）直到记录落入给定范围内。

总结一下：

• 在树中搜索第一个好的结果。 成本：log_f(ℓ)
• 使用找到的指针转到特定页面。 费用：1
• 扫描页面并最终扫描其他页面。 费用：数量。的相关页面

最终成本（以页面访问量表示）是

日志_ƒ(ℓ) + 1 + #relevant-pages

其中ƒ 是扇出，ℓ 是叶数。

不幸的是，在我们的例子中，搜索键 b 上的树必须是非聚类的，因为关系已经按 a 排序

案例 2：具有 alt 的非集群树。 2个（或3个）

我们还知道，当 B⁺⁠-⁠树是非聚类时，它们在范围查询中的效率并不高。事实上，如果有一棵树有备选方案 2 或 3，我们将只存储指向记录的指针，因此对于落入范围内的每个结果，我们必须对潜在的不同页面进行页面访问（因为该关系相对于索引具有不同的顺序）。

总结一下：

• 在树中搜索第一个好的结果。 成本：log_f(ℓ)
• 按照扫描叶子（可能还有其他叶子）并为该范围内的每个元组执行不同的页面访问。 费用：数量。其他相关叶子+数量。相关元组

最终成本（以页面访问量表示）是

log_ƒ(ℓ) + #other-relevant-leaves + #relevant-tuples

请注意，元组的数量相对于页数来说相当更大！

案例 3：具有 alt 的非集群树。 1

使用备选方案 1，我们拥有树中的所有数据，因此为了执行查询，我们：

• 在树中搜索第一个好的结果。 成本：log_f(ℓ)
• 跟随扫描叶子（可能还有其他叶子）。 费用：数量。其他相关的叶子

最终成本（以页面访问量表示）是

log_ƒ(ℓ) + #other-relevant-leaves

这甚至小于（或最多等于）案例 1 的成本，但这是允许的。

---

我希望我已经足够清楚了。

注意成本以页面访问表示，因为从/到第二个存储的 I/O 操作在时间上是最昂贵的（我们忽略了在主存中扫描整个页面的成本，但我们只考虑访问它的成本）。