Oracle表连接之哈希连接

Oracle Hash join 是一种非常高效的join 算法，主要以CPU(hash计算)和内存空间(创建hash table)为代价获得最大的效率。Hash join一般用于大表和小表之间的连接，我们将小表构建到内存中，称为Hash cluster，大表称为probe表。

 

当两个表做hash join时，oracle会选择一个表作为驱动表，先根据过滤条件排除不必要的数据，然后将结果集做成hash表，放入进程的hash area，接着扫描第二张表，将记录的join字段值做hash运算，到内存的hash表里面去探测，如果探测成功，就返回数据，否则这行就丢弃掉。

 

(miki西游 @mikixiyou 原文链接: http://mikixiyou.iteye.com/blog/1709321 )

 

 

select /*+use_nl(a b)*/ a.*,b.* 
from dba_obj a,all_obj b
where a.object_id=b.object_id
and a.object_name like 'tt%'



SELECT STATEMENT, GOAL = ALL_ROWS		
 NESTED LOOPS		
  TABLE ACCESS FULL	SCOTT	DBA_OBJ
  TABLE ACCESS BY INDEX ROWID	SCOTT	ALL_OBJ
   INDEX UNIQUE SCAN	SCOTT	PK_ALL_OBJ

 

执行计划解读

两个表使用了嵌套循环连接。首先访问dba_obj表，得到全部记录。然后按照此表记录依次去扫描all_obj表，扫描过程走索引快速得到all_obj的记录。

 

 

 

select /*+use_hash(a b)*/ a.*,b.* 
from dba_obj a,all_obj b
where a.object_id=b.object_id
and a.object_name like 'tt%'



SELECT STATEMENT, GOAL = ALL_ROWS		
 HASH JOIN		
  TABLE ACCESS FULL	SCOTT	DBA_OBJ
  TABLE ACCESS FULL	SCOTT	ALL_OBJ

 

 

执行计划解读

两个表使用了哈希连接。首先访问dba_obj表，得到全部记录，进行hash运算，放到内存hash area中形成hash table，也称为hash cluster。
然后，再腾出手来，全面扫描all_obj表，每扫描到一条记录时，将join字段进行hash运算，然后到hash area中去找与dba_obj表匹配的记录。
这个行为称为probe，中文称探测。此表也称为probe表。

 

 

hash table表是保存在hash area内存区域中，而这个区域在oracle中是分配在pga中。

PGA 包括 进程内存、UGA、sort area,bitmap merge area和hash area。UGA包含session状态信息和private sql area。

 

 

使用这个10104 event可以分析hash area的内存分配情况。

 

alter system set events '10104 trace name context forever,level 2';
 
select count(*)
  from (select /*+use_hash(i g) leading(i)*/
         i.*, g.*
          from tdividenddetail i, tproductinfo g
         where i.c_fundcode = g.fundcode
           and i.d_cdate > sysdate - 100);

 

 

使用use_hash提示强制让两个表采用hash join关联，然后使用leading提示强制让i表作为驱动表。

 

在hash area中，默认采用8个partition，每个partition保存若干个 hash table的记录。这些记录又以bucket逻辑结构存储。

分析trc文件内容如下所示：

 

*** RowSrcId: 1 HASH JOIN STATISTICS (INITIALIZATION) ***
Join Type: INNER join
Original hash-area size: 3064559
Memory for slot table: 2826240
Calculated overhead for partitions and row/slot managers: 238319
Hash-join fanout: 8
Number of partitions: 8
Number of slots: 23
Multiblock IO: 15
Block size(KB): 8
Cluster (slot) size(KB): 120
Minimum number of bytes per block: 8160
Bit vector memory allocation(KB): 128
Per partition bit vector length(KB): 16
Maximum possible row length: 1708
Estimated build size (KB): 0
Estimated Build Row Length (includes overhead): 408
# Immutable Flags:
  Not BUFFER(execution) output of the join for PQ
  Evaluate Left Input Row Vector
  Evaluate Right Input Row Vector
# Mutable Flags:
  IO sync
kxhfSetPhase: phase=BUILD
kxhfAddChunk: add chunk 0 (sz=32) to slot table
kxhfAddChunk: chunk 0 (lbs=0x2b4b26b47b20, slotTab=0x2b4b26b47ce8) successfuly added
kxhfSetPhase: phase=PROBE_1
qerhjFetch: max build row length (mbl=390)
*** RowSrcId: 1 END OF BUILD (PHASE 1) ***
  Revised row length: 370
  Revised build size: 9KB
kxhfResize(enter): resize to 12 slots (numAlloc=7, max=23)
kxhfResize(exit): resized to 12 slots (numAlloc=7, max=12)
  Slot table resized: old=23 wanted=12 got=12 unload=0
*** RowSrcId: 1 HASH JOIN RESIZE BUILD (PHASE 1) ***
Total number of partitions: 8
Number of partitions which could fit in memory: 8
Number of partitions left in memory: 8
Total number of slots in in-memory partitions: 7
kxhfResize(enter): resize to 13 slots (numAlloc=7, max=12)
kxhfResize(exit): resized to 13 slots (numAlloc=7, max=13)
  set work area size to: 1753K (13 slots)
*** RowSrcId: 1 HASH JOIN BUILD HASH TABLE (PHASE 1) ***
Total number of partitions: 8
Number of partitions left in memory: 8
Total number of rows in in-memory partitions: 27
   (used as preliminary number of buckets in hash table)
Estimated max # of build rows that can fit in avail memory: 8190
### Partition Distribution ###
Partition:0    rows:3          clusters:1      slots:1      kept=1
Partition:1    rows:5          clusters:1      slots:1      kept=1
Partition:2    rows:3          clusters:1      slots:1      kept=1
Partition:3    rows:4          clusters:1      slots:1      kept=1
Partition:4    rows:6          clusters:1      slots:1      kept=1
Partition:5    rows:3          clusters:1      slots:1      kept=1
Partition:6    rows:3          clusters:1      slots:1      kept=1
Partition:7    rows:0          clusters:0      slots:0      kept=1

Revised number of hash buckets (after flushing): 27
Allocating new hash table.

Requested size of hash table: 8
Actual size of hash table: 8
Number of buckets: 64
Match bit vector allocated: FALSE

Total number of rows (may have changed): 27
Number of in-memory partitions (may have changed): 8
Final number of hash buckets: 64
Size (in bytes) of hash table: 512
qerhjBuildHashTable(): done hash-table on partition=6, index=1 last_slot#=5 rows=3 total_rows=3
qerhjBuildHashTable(): done hash-table on partition=5, index=2 last_slot#=6 rows=3 total_rows=6
qerhjBuildHashTable(): done hash-table on partition=4, index=3 last_slot#=0 rows=6 total_rows=12
qerhjBuildHashTable(): done hash-table on partition=3, index=4 last_slot#=3 rows=4 total_rows=16
qerhjBuildHashTable(): done hash-table on partition=2, index=5 last_slot#=1 rows=3 total_rows=19
qerhjBuildHashTable(): done hash-table on partition=1, index=6 last_slot#=4 rows=5 total_rows=24
qerhjBuildHashTable(): done hash-table on partition=0, index=7 last_slot#=2 rows=3 total_rows=27
kxhfIterate(end_iterate): numAlloc=7, maxSlots=13

### Hash table ###
# NOTE: The calculated number of rows in non-empty buckets may be smaller
#       than the true number.
Number of buckets with   0 rows:         42
Number of buckets with   1 rows:         18
Number of buckets with   2 rows:          4
Number of buckets with   3 rows:          0
Number of buckets with   4 rows:          0
Number of buckets with   5 rows:          0
Number of buckets with   6 rows:          0
Number of buckets with   7 rows:          0
Number of buckets with   8 rows:          0
Number of buckets with   9 rows:          0
Number of buckets with between  10 and  19 rows:          0
Number of buckets with between  20 and  29 rows:          0
Number of buckets with between  30 and  39 rows:          0
Number of buckets with between  40 and  49 rows:          0
Number of buckets with between  50 and  59 rows:          0
Number of buckets with between  60 and  69 rows:          0
Number of buckets with between  70 and  79 rows:          0
Number of buckets with between  80 and  89 rows:          0
Number of buckets with between  90 and  99 rows:          0
Number of buckets with 100 or more rows:          0
### Hash table overall statistics ###
Total buckets: 64 Empty buckets: 42 Non-empty buckets: 22
Total number of rows: 27
Maximum number of rows in a bucket: 2
Average number of rows in non-empty buckets: 1.227273
*** 2012-10-31 10:37:15.443
qerhjFetch: max probe row length (mpl=0)
*** RowSrcId: 1, qerhjFreeSpace(): free hash-join memory
kxhfRemoveChunk: remove chunk 0 from slot table

 

 

附加：Alibaba DBA Team 关于Oracle hash join 的文档

 

当做hash join时，oracle会选择一个表作为驱动表，先根据过滤条件排除不必要的数据，然后将结果集做成hash表，放入进程的hash area，接着扫描第二张表，将行的键值做hash运算，到内存的hash表里面去探测，如果探测成功，就返回数据，否则这行就丢弃掉这个是最基本的解释，实际情况中，考虑到单个进程PGA的大小，oracle不会让进程任意的消耗OS内存，hash area是有一定限制的，所以在oracle中，hash也有三种模式：
optimal，onepass，multipass

 

optimal:当驱动结果集生成的hash表全部可以放入PGA的hash area时，称为optimal，大致过程如下：
1.先根据驱动表，得到驱动结果集
2.在hash area生成hash bulket，并将若干bulket分成一组，成为一个partition，还会生成一个bitmap的列表，每个bulket在上面占一位
3.对结果集的join键做hash运算，将数据分散到相应partition的bulket中，当运算完成后，如果键值唯一性较高的话，bulket里的数据会比较均匀，也有可能有的桶里面数据会是空的，这样bitmap上对应的标志位就是0，有数据的桶，标志位会是1
4.开始扫描第二张表，对jion键做hash运算，确定应该到某个partition的某个bulket去探测，探测之前，会看这个bulket的bitmap是否会1，如果为0，表示没数据，这行就直接丢弃掉
5.如果bitmap为1，则在桶内做精确匹配，判断OK后，返回数据

这个是最优的hash join，他的成本基本是两张表的full table scan，在加微量的hash运算

 

onepass
如果进程的pga很小，或者驱动表结果集很大，超过了hash area的大小，会怎么办？当然会用到临时表空间，此时oracle的处理方式稍微复杂点需奥注意上面提到的有个partition的概念，可以这么理解，数据是经过两次hash运算的，先确定你的partition，再确定你的bulket，假设hash area小于整个hash table，但至少大于一个partition的size，这个时候走的就是onepass
当我们生成好hash表后，状况是部分partition留在内存中，其他的partition留在磁盘临时表空间中，当然也有可能某个partition一半在内存，一半在磁盘，剩下的步骤大致如下：
1.扫描第二张表，对join键做hash运算，确定好对应的partition和bulket
2.查看bitmap，确定bulket是否有数据，没有则直接丢弃
3.如果有数据，并且这个partition是在内存中的，就进入对应的桶去精确匹配，能匹配上，就返回这行数据，否则丢弃
4.如果partition是在磁盘上的，则将这行数据放入磁盘中暂存起来，保存的形式也是partition，bulket的方式
5.当第二张表被扫描完后，剩下的是驱动表和探测表生成的一大堆partition，保留在磁盘上
6.由于两边的数据都按照相同的hash算法做了partition和bulket，现在只要成对的比较两边partition数据即可，并且在比较的时候，oracle也做了优化处理，没有严格的驱动与被驱动关系，他会在partition对中选较小的一个作为驱动来进行，直到磁盘上所有的partition对都join完

可以发现，相比optimal，他多出的成本是对于无法放入内存的partition，重新读取了一次，所以称为onepass，只要你的内存保证能装下一个partition，oracle都会腾挪空间，每个磁盘partition做到onepass

 

multipass
这是最复杂，最糟糕的hash join，此时hash area小到连一个partition也容纳不下，当扫描好驱动表后，可能只有半个partition留在hash area中，另半个加其他的partition全在磁盘上,剩下的步骤和onepass比价类似，不同的是针对partition的处理
由于驱动表只有半个partition在内存中，探测表对应的partition数据做探测时，如果匹配不上，这行还不能直接丢弃，需要继续保留到磁盘，和驱动表剩下的半个partition再做join，这里举例的是内存可以装下半个partition，如果装的更少的话，反复join的次数将更多，当发生multipass时，partition物理读的次数会显著增加