DB2表连接操作是我们经常可以见到的，下文对DB2表连接原理作了详尽的阐述分析，如果您对此方面感兴趣的话，不妨一看。
在DB2中，优化器可以选择嵌套连接或合并连接，如果得到正确支持的话，还可以选择散列连接。如果系统调优得正确，散列连接可显著提高某些查询的性能。DB2优化器可以在执行连接时选择不同方法：在缺省情况下，它在嵌套循环连接（nested loop join）与合并连接（merge join）之间选择。当设置了特殊环境变量时，它还可以选择散列连接（hash join）。
两个表之间的连接是这样操作的：将一个表中的行与另一个表中的行并置在一起。另外，可以指定条件以定义并置哪些行。为执行这一操作，DB2 可以选择不同的连接方法。在连接两个表时，无论使用哪种连接方法，总有一个表被选为外表（outer table）而另一个表被选为内表（inner table）。优化器根据所选连接方法的成本和类型决定哪个是外表、哪个是内表。首先访问外表，并且只扫描一次。根据连接的类型和存在的索引，可以多次扫描内表。还有一点也很重要，要记住即使您试图连接两个以上的表，优化器也将每次只连接两个表，并在必要时保存中间结果。要理解散列连接方法的优势，先理解其它连接方法的工作原理也很重要。
嵌套循环连接
正如我们前面提到的那样，外表只被扫描一次。对于嵌套循环连接，要在内表中找到与外表中每一行相匹配的行有两种方法：
扫描内表。即，读取内表中的每一行，并且针对该行决定是否应将其与正在考虑的外表中的行相连接。
对内表上的连接列进行索引查找。当用于连接的谓词所包含的列在内表的索引中时，这种方法是可行的。这极大地减少了在内表中访问的行数。
在嵌套循环连接中，决定哪个是外表、哪个是内表非常重要，因为外表只扫描一次，而针对外表中的每一行，都要访问一次内表。正如前面提到的那样，优化器用成本模型来决定谁是外表谁是内表。优化器做此决定时会考虑几个因素：
表的大小
缓冲
谓词
排序要求
是否存在索引
连接列不能是 LONG 或 LOB 字段。
合并连接
合并连接需要一个等式连接谓词（即具有 table1.column = table2.column 格式的谓词）。它还要求根据连接列对输入表进行排序。通过扫描现有索引或在进行连接之前对表进行排序就可以做到这一点。连接列不能是 LONG 或 LOB 字段。
同时扫描两个表，以查找匹配行。外表和内表都只扫描一次，除非外表中有重复的值，那样的话可能要再次扫描内表的某些部分。因为表通常只被扫描一次，所以决定哪个是外表、哪个是内表不象在其它连接方法中那么重要。尽管如此，由于可能有重复的值，所以优化器通常选择重复值较少的表作为外表。但是，优化器最终还是使用成本模型来决定谁是外表谁是内表。
散列连接
散列连接需要一个或多个等式连接谓词，其中每个谓词的列类型相同。就 CHAR 类型而言，长度必须相同。就 DECIMAL 类型而言，精度和小数位必须相同。同样，连接列不能是 LONG 或 LOB 字段。散列连接可处理多个等式谓词这一事实相对于合并连接是一大优势，后者只能处理一个等式谓词。
对于散列连接，首先扫描内表（也称为构建表，bulid table），表中的行被复制到内存缓冲区。根据“散列代码（hash code）”，这些缓冲区被分为几个分区，散列代码是根据连接谓词中的列计算出来的。如果内存中没有足够的空间容纳整个表，则有些分区被写入磁盘上的临时表。然后扫描外表（称为探测表，probe table）。对于探测表中的每一行，对连接列应用同一散列算法。如果所获得的散列代码与构建行的散列代码相匹配，则比较实际的连接列。如果与探测表行匹配的分区在内存中，则比较会立即进行。如果分区被写入临时表，则探测行也被写入临时表。最后，处理包含同一分区中的行的临时表以进行匹配。
由于将构建表保存在内存中所具有的好处，优化器通常选择较小的表作为构建表，以避免必须将该表溢出（spill）到磁盘上。但是，要再次强调的是，成本模型最终决定哪个表是内表、哪个表是外表。
选择哪种连接方法？
到目前为止，我们已经讨论了在DB2中可用的不同连接方法。正如我们所知，初看起来，某些方法与其它方法相比是更好的选择。例如，与根据外表的每一行扫描内表的嵌套循环连接相比，合并连接具有只对表扫描一次的优势。于是，合并连接似乎是一个更好的选择；但是，如果存在索引的话，则嵌套循环会是更好的选择。
同样地，与合并连接相比，散列连接似乎是更好的选择，因为它不需要在执行前对输入表排序，但如果我们需要保持外表中行的次序，则合并连接或嵌套循环连接可能是更好的选择 — 散列连接不能保证维持次序，因为它可能溢出到磁盘而那样会破坏次序。
【编辑推荐】
