我承认我标题党了。
相信凡是写过几行服务端代码的同学都会回答: "当然了解"。但是我这里讨论的不是join的语法，而是实现join的具体算法。其实我也不了解，最近在看《Column-Stores vs. Row-Stores: How Different Are They Really?》， 发现里面提到了数据库里面的各种join的实现，因此特地把各种join的实现方法找出来学一下，挺有意思。
在具体介绍各种join算法之前我们先统一下名词：
- 我们要join的两个表分别为
R和S。 -
|R|表示R表里面数据的条数。 -
Pr表示要把R的全部数据加载到内存里面，需要的内存页的数量。
Nested loop join
Nested loop join是Join里面最简单的一种实现，它把R表里面的每条记录取出来，跟S表里面的每条记录进行比较、把符合Join条件的两个对应的记录输出为Join的结果。Nested loop join的伪代码大概是这样的:
For each tuple r in R do
For each tuple s in S do
If r and s satisfy the join condition
Then output the tuple <r,s>
可以看出这个算法就是嵌套的两个for循环，这也就是nested loop这个名字的由来。
Wikipeda对这个算法的评价是Naive。确实Naive, 是个写代码得实现Join都会这么实现。它的I/O复杂度是:
O(|R| * |S|)
因为对于R里面的每一条数据，S里面的每一条数据都要扫描一遍来join一下。
前段时间在研究Apache Beam, Beam里面并不直接支持Join语法，因此要Join的话得自己实现，因此实现了一个，很是费了一番功夫。现在想想我实现的其实就是Nested Loop Join啊！
虽然我把Join实现出来了，但是我不知道它有自己的学名: Nested Loop Join；也不知道它其实是最Naive的Join，还有其它效率更好的Join。真的是要多读书啊。
Block nested loop
Block nested loop是对Nested loop join的一种优化，优化的手段是: 对于R表里面的记录，我们不再一条一条的join了，而是一批一批的join，这所谓的一批通常是一个内存页(Page)，每次加载R的一个页, 把这个页里面的记录放进一个hashtable, S表的数据要跟R比较的时候就不用跟R里面的每条数据比较了，只需要对这个hashtable进行查找操作就好了。这样扫描的次数就大大降低了。
它的I/O复杂度是:
O(Pr * Ps / M)
这里M是可用的内存里面能容纳的页的个数。
Block其实表达的就是批量的意思。
批量这个优化手段在很多问题下都有效。
Hash join
两个表join的时候，如果其中一个表比较小（R），小到可以放进内存，那么把这个表的所有的数据放进内存构建一个hashtable, 这个hashtable的key是要Join的字段的值，value是对应的数据记录。
在Join的时候我们只需要对S进行一遍扫描，对于每条记录，查找前面的hashtable来看看是否有符合的记录，如果找到了，那么Join上了，输出对应的记录，否则就丢弃掉对应的记录。
它的I/O复杂度是:
O(|S|)
当然，上面说的这种是理想的情况: 其中一个表可以完全放进内存，很多情况下没有这么理想。
而且hash join并不是对任何join都可以应用，由于它是速度优势是来源于hash算法的，因此只能应用于等值join的场景。
如果R没有那么小，怎么办？因此Hash join的更一般的表述是这样的:
for (r in R):
add r to in_memory_hash_table
if size(hashtable) > max_memory_size:
scan_S_to_join();
in_memory_hash_table.clear();
也就是分批把R表的数据加载进内存，然后跟S进行join，它的I/O复杂度是:
O(Pr * Ps / M)
可以看出跟Block nested loop的I/O复杂度是一样的。
Grace hash join
当R无法完全加载到内存的时候，Hash join还是要对S加载扫描很多遍，这个扫描加载的操作非常的昂贵。因此Grace hash join对这一点进行了优化。在Grace hash join里面，我们首先利用一个hash函数对R和S的数据进行分区，分区的规则是:
hash_func(join-field)
然后对于被分到同一个分区的R和S的数据分别进行join; 最后把所有分片join的数据合并起来就是最终的join结果。因此Grace hash join的主要的贡献就在于:
它使得每条数据只需要Join一次。
它的I/O复杂度为:
O(Pr + Ps)
比Block Nested Loop的I/O复杂度大大的优化了。
为什么叫Grace hash join? 因为这个算法最早是一个叫做GRACE的数据库系统里面实现的。
Sort-merge join
Sort-merge join又叫merge join。这个算法首先根据要join的字段对R和S进行排序, 然后通过同时对R和S进行线性扫描进行merge扫描。它的伪代码如下：
function sortMerge(relation left, relation right, attribute a)
var relation output
var list left_sorted := sort(left, a) // Relation left sorted on attribute a
var list right_sorted := sort(right, a)
var attribute left_key, right_key
var set left_subset, right_subset // These sets discarded except where join predicate is satisfied
advance(left_subset, left_sorted, left_key, a)
advance(right_subset, right_sorted, right_key, a)
while not empty(left_subset) and not empty(right_subset)
if left_key = right_key // Join predicate satisfied
add cartesian product of left_subset and right_subset to output
advance(left_subset, left_sorted, left_key, a)
advance(right_subset, right_sorted, right_key, a)
else if left_key < right_key
advance(left_subset, left_sorted, left_key, a)
else // left_key > right_key
advance(right_subset, right_sorted, right_key, a)
return output
// Remove tuples from sorted to subset until the sorted[1].a value changes
function advance(subset out, sorted inout, key out, a in)
key := sorted[1].a
subset := emptySet
while not empty(sorted) and sorted[1].a = key
insert sorted[1] into subset
remove sorted[1]
它的时间复杂度为:
O(Pr + Ps + Pr * log(Pr) + Ps * log(Ps))
其中Pr * log(Pr)其实就是对R进行快排所需要的时间。根据大O表示法，上面的复杂度公式可以简化为:
O(Pr * log(Pr) + Ps * log(Ps))
可以看出Sort-merge join里面时间消耗最多的就在这个排序上。
其实Grace hash join跟Sort-merge join有点类似，都是从节省数据扫描次数的角度来进行优化的:
- Grace hash join对数据进行分片，分而治之。
- Sort-merge join是先对数据进行排序，其实也是分而治之的意思。
其实排序之后就可以进行分片了。排序可以看做一种特殊的分片。
结论
- 批量、分而治之在很多问题域下面都是非常有效的优化方法。
- hash是个很有用的东西。
- 没事多看书。
