浅谈数据库Join的实现原理

Join的实现算法有三种，分别是Nested Loops Join, Merge Join, Hash Join。

DB2、SQL Server和Oracle都是使用这三种方式，不过Oracle选择使用nested loop的条件跟SQL Server有点差别，内存管理机制跟SQL Server不一样，因此查看执行计划，Oracle中nested loops运用非常多，而merge和hash方式相对较少，SQL Server中，merge跟hash方式则是非常普遍。

一.Nested Loopsb Join

1.定义

Nested Loops也称为嵌套迭代，它将一个联接输入用作外部输入表（显示为图形执行计划中的顶端输入），将另一个联接输入用作内部（底端）输入表。外部循环逐行消耗外部输入表。内部循环为每个外部行执行，在内部输入表中搜索匹配行。最简单的情况是，搜索时扫描整个表或索引；这称为单纯嵌套循环联接。如果搜索时使用索引，则称为索引嵌套循环联接。如果将索引生成为查询计划的一部分（并在查询完成后立即将索引破坏），则称为临时索引嵌套循环联接。伪码表示如下：

for each row R1 in the outer table

for each row R2 in the inner table

if R1 joins with R2

return (R1, R2)

2.应用场景

适用于outer table(有的地方叫Master table)的记录集比较少(

inner table被outer table驱动，outer table返回的每一行都要在inner table中检索到与之匹配的行。当然也可以用ORDERED 提示来改变CBO默认的驱动表，使用USE_NL(table_name1 table_name2)可是强制CBO 执行嵌套循环连接。

cost = outer access cost + (inner access cost * outer cardinality)

3.常用于执行的连接

Nested Loops常执行Inner Join(内部联接)、Left Outer Join(左外部联接)、Left Semi Join(左半部联接)和Left Anti Semi Join(左反半部联接)逻辑操作。

Nested Loops通常使用索引在内部表中搜索外部表的每一行。根据预计的开销，Microsoft SQL Server决定是否对外部输入进行排序来改变内部输入索引的搜索位置。

将基于所执行的逻辑操作返回所有满足 Argument 列内的（可选）谓词的行。

二.Merge Join

1.定义

Merge Join第一个步骤是确保两个关联表都是按照关联的字段进行排序。如果关联字段有可用的索引，并且排序一致，则可以直接进行Merge Join操作；否则，SQL Server需要先对关联的表按照关联字段进行一次排序（就是说在Merge Join前的两个输入上，可能都需要执行一个Sort操作，再进行Merge Join）。

两个表都按照关联字段排序好之后，Merge Join操作从每个表取一条记录开始匹配，如果符合关联条件，则放入结果集中；否则，将关联字段值较小的记录抛弃，从这条记录对应的表中取下一条记录继续进行匹配，直到整个循环结束。

在多对多的关联表上执行Merge Join时，通常需要使用临时表进行操作。例如A join B使用Merge Join时，如果对于关联字段的某一组值，在A和B中都存在多条记录A1、A2...An、B1、B2...Bn，则为A中每一条记录A1、A2...An，都必须在B中对所有相等的记录B1、B2...Bn进行一次匹配。这样，指针需要多次从B1移动到Bn，每一次都需要读取相应的B1...Bn记录。将B1...Bn的记录预先读出来放入内存临时表中，比从原数据页或磁盘读取要快。

2.应用场景另

用在数据没有索引但是已经排序的情况下。

通常情况下hash join的效果都比Sort merge join要好，然而如果行源已经被排过序，在执行排序合并连接时不需要再排序了，这时Sort merge join的性能会优于hash join。可以使用USE_MERGE(table_name1 table_name2)来强制使用Sort merge join。

cost = (outer access cost * # of hash partitions) + inner access cost

3.常用于执行的连接

Merge Join常执行Inner Join(内部联接)、Left Outer Join(左外部联接)、Left Semi Join(左半部联接)、Left Anti Semi Join(左反半部联接)、Right Outer Join(右外部联接)、Right Semi Join(右半部联接)、Right Anti Semi Join(右反半部联接)和Union(联合)逻辑操作。

在 Argument 列中，如果操作执行一对多联接，则 Merge Join 运算符将包含 MERGE:() 谓词；如果操作执行多对多联接，则该运算符将包含 MANY-TO-MANY MERGE:() 谓词。Argument 列还包含一个用于执行操作的列的列表，该列表以逗号分隔。Merge Join 运算符要求在各自的列上对两个输入进行排序，这可以通过在查询计划中插入显式排序操作来实现。如果不需要显式排序（例如，如果数据库内有合适的 B 树索引或可以对多个操作（如合并联接和对汇总分组）使用排序顺序），则合并联接尤其有效。

三.Hash Join

1.定义

Hash Match有两个输入：build input（也叫做outer input）和probe input（也叫做inner input），不仅用于inner/left/right join等，象union/group by等也会使用hash join进行操作，在group by中build input和probe input都是同一个记录集。

Hash Match操作分两个阶段完成：Build（构造）阶段和Probe（探测）阶段。

Build（构造）阶段主要构造哈希表(hash table)。在inner/left/right join等操作中，表的关联字段作为hash key；在group by操作中，group by的字段作为hash key；在union或其它一些去除重复记录的操作中，hash key包括所有的select字段。

Build操作从build input输入中取出每一行记录，将该行记录关联字段的值使用hash函数生成hash值，这个hash值对应到hash table中的hash buckets（哈希表目）。如果一个hash值对应到多个hash buckts，则这些hash buckets使用链表数据结构连接起来。当整个build input的table处理完毕后，build input中的所有记录都被hash table中的hash buckets引用/关联了。

Probe（探测）阶段，SQL Server从probe input输入中取出每一行记录，同样将该行记录关联字段的值，使用build阶段中相同的hash函数生成hash值，根据这个hash值，从build阶段构造的hash table中搜索对应的hash bucket。hash算法中为了解决冲突，hash bucket可能会链接到其它的hash bucket，probe动作会搜索整个冲突链上的hash bucket，以查找匹配的记录。

如果build input记录数非常大，构建的hash table无法在内存中容纳时，SQL Server分别将build input和probe input切分成多个分区部分（partition），每个partition都包括一个独立的、成对匹配的build input和probe input，这样就将一个大的hash join切分成多个独立、互相不影响的hash join，每一个分区的hash join都能够在内存中完成。SQL Server将切分后的partition文件保存在磁盘上，每次装载一个分区的build input和probe input到内存中，进行一次hash join。这种hash join叫做Grace Hash join，使用的Grace Hash Join算法。

2.应用场景

适用于两个表的数据量差别很大。但需要注意的是：如果HASH表太大，无法一次构造在内存中，则分成若干个partition，写入磁盘的temporary segment，则会多一个I/O的代价，会降低效率，此时需要有较大的temporary segment从而尽量提高I/O的性能。

可以用USE_HASH(table_name1 table_name2)提示来强制使用散列连接。如果使用散列连HASH_AREA_SIZE 初始化参数必须足够的大，如果是9i，Oracle建议使用SQL工作区自动管理，设置WORKAREA_SIZE_POLICY 为AUTO，然后调整PGA_AGGREGATE_TARGET 即可。

也可以使用HASH_JOIN_ENABLED=FALSE(默认为TRUE)强制不使用hash join。

cost = (outer access cost * # of hash partitions) + inner access cost

3.常用于执行的链接

Hash Match运算符通过计算其生成输入中每行的哈希值生成哈希表。HASH:()谓词以及一个用于创建哈希值的列的列表出现在Argument列内。然后，该谓词为每个探测行（如果适用）使用相同的哈希函数计算哈希值并在哈希表内查找匹配项。如果存在残留谓词（由 Argument 列中的 RESIDUAL:() 标识），则还须满足此残留谓词，只有这样行才能被视为是匹配项。行为取决于所执行的逻辑操作：

(1)对于联接，使用第一个（顶端）输入生成哈希表，使用第二个（底端）输入探测哈希表。按联接类型规定的模式输出匹配项（或不匹配项）。如果多个联接使用相同的联接列，这些操作将分组为一个哈希组。

(2)对于非重复或聚合运算符，使用输入生成哈希表（删除重复项并计算聚合表达式）。生成哈希表时，扫描该表并输出所有项。

(3)对于 union 运算符，使用第一个输入生成哈希表（删除重复项）。使用第二个输入（它必须没有重复项）探测哈希表，返回所有没有匹配项的行，然后扫描该哈希表并返回所有项。

四.性能分析

Hash join的主要资源消耗在于CPU(在内存中创建临时的hash表，并进行hash计算)，而merge join的资源消耗主要在于磁盘I/O(扫描表或索引)。在并行系统中，hash join对CPU的消耗更加明显。所以在CPU紧张时，最好限制使用hash join。

在绝大多数情况下，hash join效率比其他join方式效率更高：

在Sort-Merge Join(SMJ)，两张表的数据都需要先做排序，然后做merge。因此效率相对最差;

Nested-Loop Join(NL)效率比SMJ更高。特别是当驱动表的数据量很大(集的势高)时。这样可以并行扫描内表。

Hash join效率最高，因为只要对两张表扫描一次，Merge Join(合并联接)本身的速度很快，但如果需要排序操作，选择合并联接就会非常费时。然而，如果数据量很大且能够从现有 B 树索引中获得预排序的所需数据，则合并联接通常是最快的可用联接算法。如果是无序的数据，Merge Join首先做的是排序，如果数据量大，排序就会溢出到tempdb, 效率就将低了。

如果外部输入很小(

如果两个表的数据量差别很大,则使用Hash Match。但需要注意的是：如果HASH表太大，无法一次构造在内存中，则分成若干个partition，写入磁盘的temporary segment，则会多一个I/O的代价，会降低效率，此时需要有较大的temporary segment从而尽量提高I/O的性能。Hash join的主要资源消耗在于CPU(在内存中创建临时的HASH表，并进行HASH计算)，而Merge join的资源消耗主要在于磁盘I/O(扫描表或索引)。

五.优化原则

1.若有单行谓词，则他的表一定是驱动表（select * from employees e,departments d where e.department_id=d.department_id and e.department_id=100 and salary=10000; 上面的语句中e.department_id=d.department_id是连接谓词，e.department_id=100是非连接谓词（对连接列的限制），salary=10000是单行谓词（对非连接列的限制））

2.外连接时，一定是用显示的行数比较多的那个表作为驱动表。如：

select e.employee_id,e.department_id,d.manager_id,d.location_id from employees e right join departments d on e.department_id=d.department_id

则departments表显示的行数一定大于等于employees表，所以应该要以departments表作为驱动表，如果以employees表作为驱动表，则departments表中多显示的那几行就显示不出来了

4.一般情况下，Hash Join处理代价非常高，是数据库服务器内存和CPU的头号杀手之一，尤其是涉及到分区（数据量太大导致内存不够的情况，或者并发访问很高导致当前处理线程无法获得足够的内存，那么数据量不是特大的情况下也可能需要进行分区），为了尽快的完成所有的分区步骤，将使用大量异步的I/O操作，因此期间单一一个线程就可能导致多个磁盘驱动器出于忙碌状态，这很有可能阻塞其它线程的执行。

5. 要避免大数据的Hash Join，尽量将其转化为高效的Merge Join、Nested Loops。可能使用的手段有表结构设计、索引调整设计、SQL优化，以及业务设计优化。例如冗余字段的运用，将统计分析结果用service定期跑到静态表中，适当的冗余表，使用AOP或类似机制同步更新等。

6. 尽量减少join两个输入端的数据量。这一点比较常犯的毛病是，条件不符合SARG((Searchable Arguments)，在子查询内部条件给的不充分（SQL过于复杂情况下SQL Server查询优化器经常犯傻，写在子查询外部的条件不会被用在子查询内部，影响子查询内部的效率或者是跟子查询再join时候的效率）。