为什么hash join的复杂度是O(n+m)？答案

【问题标题】：Why is the complexity of hash join O(n+m)?为什么hash join的复杂度是O(n+m)？
【发布时间】：2015-05-28 10:04:49
【问题描述】：

我在网上搜索了一下，发现连接两张表的Hash Join算法的复杂度据说是O(N+M)，其中N和M是两张表的元组个数。

我想知道为什么它是 O(N+M)，而不是最坏情况下的 O(N*M)？

据我所知，Hash Join 是 equi join 的一种实现：给定两个表 R 和 S，它是从它们的叉积 R*S 中选择元组 t，其中 t[R.A] = t[S.A]， A是R和S的共同属性。

注意事项： 1) 我想知道复杂度是否为 O(N+M)，尤其是当加入属性中的数据值不唯一时（即我们没有加入关键属性）。 2) 请注意，加入属性 A 可能是也可能不是键。

【问题讨论】：

你有链接到这句话的地方吗？
Big Os 在数据库中没有那么有用和误导，主要开销是网络/磁盘延迟
@SleimanJneidi 如果我们假设整个哈希连接发生在内存中，那么 OP 会更有意义吗？
@TimBiegeleisen 是的。特别是因为哈希表可以通过排除元组而不实际读取然后一遍又一遍地比较它们的所有值来避免大量磁盘访问。
@Thilo 例如，[1] stackoverflow.com/questions/2065754/… 和 [2] stackoverflow.com/questions/5557964/perform-joins-in-on-time

【解决方案1】：

搜索算法基本是：

从 R (O(n)) 散列每个元组
从 S (O(m)) 散列每个元组

2.1 每次对来自 S 的元组进行散列时，在 R 的散列中查找 (O(1))

2.2 仅当为 R 找到匹配的哈希时，比较实际的元组值 (O(1))

因此，您只需要为每个元组 (n+m) 计算一个哈希并进行 m 次哈希查找，理想情况下每个 O(1)。

当然，如果哈希函数不适合实际数据，或者哈希表太小，哈希查找仍然是 O(1)，但是你可能需要做很多完整的元组比较，其中大部分会产生false。因此，worst 最坏情况，对于 worst case 哈希表，再次接近 O(n*m)。

【讨论】：

我也怀疑如果你不能在内存中完成整个过程，那么性能也会偏离O(N+M)。
我不这么认为。请记住 O(n) = O(c*n)。因此，对于 O 表示法，如果访问每个条目需要 1 毫秒或 100 毫秒，则没有任何区别。
@HannoBinder 感谢您的回答！我的困惑来自上面的步骤 2.2：如果 R 中有许多元组都可以匹配 S 中的元组 t1，那么它不应该是 O(1)。例如，在极端情况下，R 中的每个元组都可以匹配 t1，那么 2.2 的复杂度将是 O(n)，n 是 R 的大小。我错在哪里了吗？
当连接属性 A 都是表 R 和 S 的键时，复杂度肯定是 O(m+n)，对吧？
这完全取决于哈希函数和哈希表的大小。选择不当的哈希函数可能会将许多/所有元组投影到单个哈希值上，就好像它们是相同的值一样。一个完美的散列函数将在散列值和元组之间创建 1:1 的关系。 OTOH，这取决于我们是否严格谈论 relations，它们是 sets 元组，因此没有重复。