【问题标题】:Why are there two leaf nodes in this B-Tree lookup?为什么在这个 B-Tree 查找中有两个叶子节点?
【发布时间】:2015-10-19 19:56:06
【问题描述】:

在这

图形,我们正在 B 树中查找employee_id 123 和subsidary_id 20(来自关于数据库索引的教程)。有两个叶子节点从树上分支出来。这是纯粹的演示,还是我遗漏了什么,因为我认为唯一需要检查的叶节点将是顶部节点,因为它的employee_id max 123 和 subsidary_id max 27。

【问题讨论】:

  • 呃,那些不是 123的节点呢?你不打算把它们也存放在树上吗?
  • 是的,但为什么它甚至会首先关注125 | 30123 | 27 包含123 | 20,所以我不明白为什么它会查看125 | 30
  • 不会,但是为什么这会阻止您在图表中显示该节点?我认为您可能误读了插图;箭头表示指针,而不是数据流或程序流。
  • 我认为你可能是对的,@rb612。 (123,18) 所指的节点太小不用看,(123, 27) 以外的节点也不需要看,因为最大值大于key,所以key只能在一页上。
  • 是树图,不是查找图。

标签: database indexing tree nodes b-tree


【解决方案1】:

图表本身并未显示该特定搜索的操作,而是显示了树的本地化部分,因此对于特定查询,我不会对其进行过多解读。

您在搜索键 123-20 方面是绝对正确的,您永远不需要跟随到第二个叶节点的链接(通过左侧的分层链接,或从上方的顺序链接)。

但是(如果没有看到源材料就很难判断),这张图很可能也可以用于其他用途。

它显示连续叶节点之间的链接这一事实意味着使用索引查找来定位特定条目,然后按顺序处理它们将非常容易。

我的意思是这样的查询:“给我所有员工 ID 为 123 的记录”,或“给我所有员工 ID 介于 123456 之间的记录”,或“给我所有记录employeeID/subsidiaryID 订单”。

所有这些查询都需要使用分层路径查找特定记录(尽管最后一个可能有更快的路径直接到第一条记录),然后按照顺序路径查找后续记录。

此外,20 的子 ID 都是红色的这一事实意味着这将是一个理想的机会来教育读者employee-subsidiary 索引不一定是所有查询的最佳索引。换句话说,一个高效的查询“给我来自子公司20 的所有记录”会更好地使用另一个索引(一个仅包含子公司 ID)。

这是我最好的猜测,看看教程看看该图是否用于其他用途是值得的。


当然,可能是编写教程的人不会费心创建新图形,因此只需使用来自不同问题的图形,或教程的早期迭代:- ) 我以前就犯过这样的错误。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2011-03-31
    • 1970-01-01
    • 2017-03-13
    • 1970-01-01
    • 1970-01-01
    • 2017-02-24
    • 2023-02-16
    • 1970-01-01
    相关资源
    最近更新 更多