oracle表链接方式对比实例

时间 2019-11-07

原文原文链接

在Oracle中，肯定链接操做类型是执行计划生成的重要方面。各类链接操做类型表明着不一样的链接操做算法，不一样的链接操做类型也适应于不一样的数据量和数据分布状况。算法

不管是Nest Loop Join（嵌套循环），仍是Merge Sort Join（合并排序链接），都是适应于不一样特殊状况的古典链接方法。Nest Loop Join算法虽然能够借助链接列索引，可是带来的随机读成本过大。而Merge Sort Join虽然能够减小随机读的状况，可是带来的大规模Sort操做，对内存和Temp空间压力过大。两种算法在处理海量数据的时候，若是是海量随机读仍是海量排序，都是不能被接受的链接算法。本篇中，咱们介绍目前比较经常使用的一种链接方式Hash Join链接。缓存

一、Hash Join（哈希链接）原理 ide

从Oracle 7.3开始，Hash Join正式进入优化器执行计划生成，只有CBO才能使用Hash Join操做。本质上说，Hash Join链接是借助Hash算法，连带小规模的Nest Loop Join，同时利用内存空间进行高速数据缓存检索的一种算法。函数

下面咱们分步骤介绍Hash Join算法步骤： oop

i. Hash Join链接对象依然是两个数据表，首先选择出其中一个“小表”。这里的小表，就是参与链接操做的数据集合数据量小。对链接列字段的全部数据值，进行Hash函数操做。Hash函数是计算机科学中常用到的一种处理函数，利用Hash值的快速搜索算法已经被认为是成熟的检索手段。Hash函数处理过的数据特征是“相同数据值的Hash函数值必定相同，不一样数据值的Hash函数值可能相同”；性能

ii. 通过Hash处理过的小表链接列，连同数据一块儿存放到Oracle PGA空间中。PGA中存在一块空间为hash_area，专门存放此类数据。而且，依据不一样的Hash函数值，进行划分Bucket操做。每一个Bucket中包括全部相同hash函数值的小表数据。同时创建Hash键值对应位图。优化

iii. 以后对进行Hash链接大表数据链接列依次读取，而且将每一个Hash值进行Bucket匹配，定位到适当的Bucket上（应用Hash检索算法）； spa

iv. 在定位到的Bucket中，进行小规模的精确匹配。由于此时的范围已经缩小，进行匹配的成功率精确度高。同时，匹配操做是在内存中进行，速度较Merge Sort Join时要快不少； .net

下面是一个Hash Join的执行计划。 orm

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------

Plan hash value: 779051904

----------------------------------------------------------------------------

----------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 2617 | 572K| 142 (1)| 00:00:02 |

|* 1 | HASH JOIN | | 2617 | 572K| 142 (1)| 00:00:02 |

| 2 | TABLE ACCESS FULL| SEGS | 2503 | 312K| 16 (0)| 00:00:01 |

| 3 | TABLE ACCESS FULL| OBJTS | 31083 | 2914K| 126 (1)| 00:00:02 |

----------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("SEGS"."SEGMENT_NAME"="OBJTS"."OBJECT_NAME")

从原理过程来看，Hash Join与Nest Loop Join/Merge Sort Join存在必定类似度。

首先，Hash Join同Nest Loop Join同样，进行必定的嵌套循环匹配操做，不过差别在于匹配进行随机读的范围是受限范围。不会像Nest Loop Join同样直接频繁进行全表规模的随机读。

其次，Hash Join同以前介绍过的Merge Sort Join有类似点，都是利用PGA的空间进行独立操做。Hash Join中的Bucket就是保存在内存的PGA中，有一块专门Hash_Area进行该项操做。选择小表做为驱动链接表，就是尽可能争取PGA内存中能够彻底装下小表数据，尽可能不要使用Temp表空间。这样，进行Hash匹配和精确匹配的速度就是有保证的。

最后，Hash Join使用的场景是有限制的。其中最大的一个就是链接操做仅能使用“=”链接。由于Hash匹配的过程只能支持相等操做。还有就是链接列的数据分布要尽可能作到数据分布均匀，这样产生的Bucket也会尽量均匀。这样限制匹配的速度才有保证。若是数据列分布偏移严重，Hash Join算法效率会有退化趋势。

随着系统数据量的不断增长，出现Hash Join的场景就会愈来愈多。下面经过一系列实验来肯定Hash Join的各类特性。

二、Hash Join链接实验

首先是准备实验环境。

SQL> create table segs as select * from dba_segments where wner='SYS';

Table created

SQL> create table objts as select * from dba_objects where wner='SYS';

Table created

SQL> select count(*) from segs;

COUNT(*)

----------

2503

SQL> select count(*) from objts;

COUNT(*)

----------

31083

SQL> create index idx_segs_name on segs(segment_name);

Index created

SQL> create index idx_objts_name on objts(object_name);

Index created

SQL> exec dbms_stats.gather_table_stats(user,'SEGS',cascade => true);

PL/SQL procedure successfully completed

SQL> exec dbms_stats.gather_table_stats(user,'OBJTS',cascade => true);

PL/SQL procedure successfully completed

此时，咱们对比三种链接方式的成本因素。

SQL> set autotrace traceonly;

SQL> select * from segs, objts where segs.segment_name=objts.object_name;

已选择4870行。

执行计划

----------------------------------------------------------

Plan hash value: 779051904

----------------------------------------------------------------------------

----------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 2617 | 572K| 142 (1)| 00:00:02 |

|* 1 | HASH JOIN | | 2617 | 572K| 142 (1)| 00:00:02 |

| 2 | TABLE ACCESS FULL| SEGS | 2503 | 312K| 16 (0)| 00:00:01 |

| 3 | TABLE ACCESS FULL| OBJTS | 31083 | 2914K| 126 (1)| 00:00:02 |

----------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - access("SEGS"."SEGMENT_NAME"="OBJTS"."OBJECT_NAME")

统计信息

----------------------------------------------------------

1 recursive calls

0 db block gets

814 consistent gets

0 physical reads

0 redo size

356347 bytes sent via SQL*Net to client

3940 bytes received via SQL*Net from client

326 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

4870 rows processed

SQL> select/*+use_nl(segs,objts)*/*from segs, objts where segs.segment_name=objts.object_name;

已选择4870行。

执行计划

----------------------------------------------------------

Plan hash value: 2045044449

-----------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 2617 | 572K| 5023 (1)| 00:01:01 |

| 1 | NESTED LOOPS | | | | | |

| 2 | NESTED LOOPS | | 2617 | 572K| 5023 (1)| 00:01:01 |

| 3 | TABLE ACCESS FULL | SEGS | 2503 | 312K| 16 (0)| 00:00:01 |

|* 4 | INDEX RANGE SCAN | IDX_OBJTS_NAME | 1 | | 1 (0)| 00:00:01 |

| 5 | TABLE ACCESS BY INDEX ROWID| OBJTS | 1 | 96 | 2 (0)| 00:00:01 |

-----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

4 - access("SEGS"."SEGMENT_NAME"="OBJTS"."OBJECT_NAME")

统计信息

----------------------------------------------------------

1 recursive calls

0 db block gets

5799 consistent gets

0 physical reads

0 redo size

406352 bytes sent via SQL*Net to client

3940 bytes received via SQL*Net from client

326 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

4870 rows processed

SQL> select/*+use_merge(segs,objts)*/*from segs, objts where segs.segment_name=objts.object_name;

已选择4870行。

执行计划

----------------------------------------------------------

Plan hash value: 2272228973

-------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 2617 | 572K| | 900 (1)| 00:00:11|

| 1 | MERGE JOIN | | 2617 | 572K| | 900 (1)| 00:00:11 |

| 2 | SORT JOIN | | 2503 | 312K| 920K| 90 (2)| 00:00:02 |

| 3 | TABLE ACCESS FULL| SEGS | 2503 | 312K| | 16 (0)| 00:00:01 |

|* 4 | SORT JOIN | | 31083 | 2914K| 8168K| 809 (1)| 00:00:10 |

| 5 | TABLE ACCESS FULL| OBJTS | 31083 | 2914K| | 126 (1)| 00:00:02 |

-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

4 - access("SEGS"."SEGMENT_NAME"="OBJTS"."OBJECT_NAME")

filter("SEGS"."SEGMENT_NAME"="OBJTS"."OBJECT_NAME")

统计信息

----------------------------------------------------------

1 recursive calls

0 db block gets

494 consistent gets

0 physical reads

0 redo size

427743 bytes sent via SQL*Net to client

3940 bytes received via SQL*Net from client

326 SQL*Net roundtrips to/from client

2 sorts (memory)

0 sorts (disk)

4870 rows processed

详细对比见下图：

	块读	排序	CPU成本	执行时间
Hash Join	814	0	142	0.02
NestLoopJoin	5799	0	5023	1.01
Merge Sort Join	494	2	900	0.11

三种链接方式，SQL数据量、语句相同，最后获取不一样的成本消耗。能够看出，当数据量达到万级以后，Nest Loop Join的随机读会急剧增长，带来的CPU成本和总执行时间成本也会大大增长。

而使用Merge Sort Join带来的块读是相对较少，可是付出的CPU成本和执行时间也是不可忽视的。将数据集合排序映射到内存中（可能要利用Temp Tablespace），须要消耗很大的CPU和内存资源（排序段）。

整体来讲，Hash Join在这个SQL中仍是能带来很好的综合性能的。只有块读稍大，其余指标都是能够接受的最好值。

下面咱们介绍与Hash Join相关的一些系统参数，和Hash Join进行的三种操做模式。不一样的系统参数，可能会给CBO成本运算带来影响。不一样的操做模式，帮助咱们理解PGA中的hash_area大小是如何影响到Hash Join操做的性能。