♣题目 部分
在Oracle中，表和表之间的关联方式有哪几种？
♣答案部分
目前为止，无论连接操作符如何，典型的连接类型共有3种：
① 排序合并连接（Sort Merge Join，简称SMJ），Oracle 6提供
② 嵌套循环（Nested Loops Join，简称NL），Oracle 6提供
③ 哈希连接（Hash Join，简称HJ），也叫散列连接，Oracle 7.3新增
另外，还有一种笛卡尔积（Merge Join Cartesian，简称MJC）连接，在Oracle 6版本的时候就已经提供，一般情况下，尽量避免使用。
对于Oracle 6提供的群集连接（Cluster Join）和Oracle 8提供的索引连接（Index Join），本书不做介绍。
在详细介绍这3类表连接方式之前，先创建表T_20161014_LHR_01共100行记录，T_20161014_LHR_02共100000行记录，创建脚本如下所示：
1DROP TABLE T_20161014_LHR_01 CASCADE CONSTRAINTS PURGE; 2DROP TABLE T_20161014_LHR_02 CASCADE CONSTRAINTS PURGE; 3CREATE TABLE T_20161014_LHR_01 ( 4 ID NUMBER NOT NULL, 5 N NUMBER, 6 CONTENTS VARCHAR2(4000) 7 ); 8CREATE TABLE T_20161014_LHR_02 ( 9 ID NUMBER NOT NULL,10 T_20161014_LHR_01_ID NUMBER NOT NULL,11 N NUMBER,12 CONTENTS VARCHAR2(4000)13 );14EXECUTE DBMS_RANDOM.SEED(0); 15INSERT INTO T_20161014_LHR_0116 SELECT ROWNUM, ROWNUM, DBMS_RANDOM.STRING('a', 50)17 FROM DUAL18 CONNECT BY LEVEL <= 10019 ORDER BY DBMS_RANDOM.RANDOM; 20INSERT INTO T_20161014_LHR_02 SELECT ROWNUM, ROWNUM, ROWNUM, DBMS_RANDOM.STRING('b', 50) FROM DUAL CONNECT BY LEVEL <= 10000021 ORDER BY DBMS_RANDOM.RANDOM; 22COMMIT; 23SELECT COUNT(*) FROM T_20161014_LHR_01; --10024SELECT COUNT(*) FROM T_20161014_LHR_02; --100000DROP TABLE T_20161014_LHR_01 CASCADE CONSTRAINTS PURGE;
2DROP TABLE T_20161014_LHR_02 CASCADE CONSTRAINTS PURGE;
3CREATE TABLE T_20161014_LHR_01 (
4 ID NUMBER NOT NULL,
5 N NUMBER,
6 CONTENTS VARCHAR2(4000)
7 );
8CREATE TABLE T_20161014_LHR_02 (
9 ID NUMBER NOT NULL,
10 T_20161014_LHR_01_ID NUMBER NOT NULL,
11 N NUMBER,
12 CONTENTS VARCHAR2(4000)
13 );
14EXECUTE DBMS_RANDOM.SEED(0);
15INSERT INTO T_20161014_LHR_01
16 SELECT ROWNUM, ROWNUM, DBMS_RANDOM.STRING('a', 50)
17 FROM DUAL
18 CONNECT BY LEVEL <= 100
19 ORDER BY DBMS_RANDOM.RANDOM;
20INSERT INTO T_20161014_LHR_02 SELECT ROWNUM, ROWNUM, ROWNUM, DBMS_RANDOM.STRING('b', 50) FROM DUAL CONNECT BY LEVEL <= 100000
21 ORDER BY DBMS_RANDOM.RANDOM;
22COMMIT;
23SELECT COUNT(*) FROM T_20161014_LHR_01; --100
24SELECT COUNT(*) FROM T_20161014_LHR_02; --100000（一）排序合并连接（SMJ）
如果连接属性上都建有索引，那么可利用索引已有的排序作合并连接。但如果在连接属性上没有索引时，那么需要首先对两表在连接属性上排序，对排序结果再作连接。
通常情况下，哈希连接的效果都比排序合并连接要好，然而如果行源已经被排过序，那么在执行排序合并连接时不需要再排序了，在这种情况下排序合并连接的性能会优于哈希连接。可以使用USE_MERGE(T1 T2)来强制使用排序合并连接。
如果相关联的表都是一个数量级，且其中一个或多个表在关联字段上有索引，那么此时使用该提示将可获得比其它两种JOIN方式更好的性能。需要注意的是，如果相关联的表是同一数量级，且相关联的表在关联字段上没有索引，那么该种方式下系统将会对所关联的表都进行全表扫描排序，其成本极高。所以，在有的数据库系统中，已不使用SMJ的关联方式，取而代之的是使用HJ的方式。
在Oracle数据库中有一个隐含参数“_OPTIMIZER_SORTMERGE_JOIN_ENABLED”控制着SMJ的启用和关闭，该参数默认值是TRUE，表示启用SMJ连接。
SMJ的连接方式示例如下所示：
1SYS@lhrdb> SET AUTOT TRACE EXP STAT 2SYS@lhrdb> SELECT /*+ ORDERED USE_MERGE(B) */ * 3 2 FROM T_20161014_LHR_01 A, T_20161014_LHR_02 B 4 3 WHERE A.ID = B.ID; 5100 rows selected. 6Execution Plan 7---------------------------------------------------------- 8Plan hash value: 703966114 9-------------------------------------------------------------------------------------------------10| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |11-------------------------------------------------------------------------------------------------12| 0 | SELECT STATEMENT | | 100 | 397K| | 35572 (1)| 00:07:07 |13| 1 | MERGE JOIN | | 100 | 397K| | 35572 (1)| 00:07:07 |14| 2 | SORT JOIN | | 100 | 198K| | 3 (34)| 00:00:01 |15| 3 | TABLE ACCESS FULL| T_20161014_LHR_01 | 100 | 198K| | 2 (0)| 00:00:01 |16|* 4 | SORT JOIN | | 82709 | 160M| 430M| 35569 (1)| 00:07:07 |17| 5 | TABLE ACCESS FULL| T_20161014_LHR_02 | 82709 | 160M| | 270 (2)| 00:00:04 |18-------------------------------------------------------------------------------------------------19Predicate Information (identified by operation id):20---------------------------------------------------21 4 - access("A"."ID"="B"."ID")22 filter("A"."ID"="B"."ID")23Note24-----25 - dynamic sampling used for this statement (level=2)26Statistics27----------------------------------------------------------28 7 recursive calls29 0 db block gets30 1050 consistent gets31 0 physical reads32 0 redo size33 13950 bytes sent via SQL*Net to client34 586 bytes received via SQL*Net from client35 8 SQL*Net roundtrips to/from client36 4 sorts (memory)37 0 sorts (disk)38 100 rows processedSET AUTOT TRACE EXP STAT
2SYS@lhrdb> SELECT /*+ ORDERED USE_MERGE(B) */ *
3 2 FROM T_20161014_LHR_01 A, T_20161014_LHR_02 B
4 3 WHERE A.ID = B.ID;
5100 rows selected.
6Execution Plan
7----------------------------------------------------------
8Plan hash value: 703966114
9-------------------------------------------------------------------------------------------------
10| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
11-------------------------------------------------------------------------------------------------
12| 0 | SELECT STATEMENT | | 100 | 397K| | 35572 (1)| 00:07:07 |
13| 1 | MERGE JOIN | | 100 | 397K| | 35572 (1)| 00:07:07 |
14| 2 | SORT JOIN | | 100 | 198K| | 3 (34)| 00:00:01 |
15| 3 | TABLE ACCESS FULL| T_20161014_LHR_01 | 100 | 198K| | 2 (0)| 00:00:01 |
16|* 4 | SORT JOIN | | 82709 | 160M| 430M| 35569 (1)| 00:07:07 |
17| 5 | TABLE ACCESS FULL| T_20161014_LHR_02 | 82709 | 160M| | 270 (2)| 00:00:04 |
18-------------------------------------------------------------------------------------------------
19Predicate Information (identified by operation id):
20---------------------------------------------------
21 4 - access("A"."ID"="B"."ID")
22 filter("A"."ID"="B"."ID")
23Note
24-----
25 - dynamic sampling used for this statement (level=2)
26Statistics
27----------------------------------------------------------
28 7 recursive calls
29 0 db block gets
30 1050 consistent gets
31 0 physical reads
32 0 redo size
33 13950 bytes sent via SQL*Net to client
34 586 bytes received via SQL*Net from client
35 8 SQL*Net roundtrips to/from client
36 4 sorts (memory)
37 0 sorts (disk)
38 100 rows processed（二）嵌套循环（NL）
NL是一种比较高效的连接方式，内部表循环与外部表相匹配。这个连接方法有驱动表（外部表）的概念，该连接过程是一个2层嵌套循环。
在嵌套循环连接中，Oracle读取驱动表（外部表）中的每一行，然后在被驱动表（内部表）中检查是否有匹配的行，所有被匹配的行都被放到结果集中，然后处理驱动表中的下一行。这个过程一直继续，直到驱动表中的所有行都被处理。这是从连接操作中可以得到第一个匹配行的最快的方法之一，这种类型的连接可以用在需要快速响应的语句中。
嵌套循环连接可以先返回已经连接的行，而不必等待所有的连接操作处理完才返回数据，这可以获取快速的响应。嵌套循环连接适用于大表和小表的关联，一般小表作为驱动表。
NL的连接方式示例如下所示：
1SYS@lhrdb> SET AUTOT TRACE EXP STAT 2SYS@lhrdb> SELECT /*+ LEADING(A) USE_NL(B) */ * 3 2 FROM T_20161014_LHR_01 A, T_20161014_LHR_02 B 4 3 WHERE A.ID = B.ID; 5100 rows selected. 6Execution Plan 7---------------------------------------------------------- 8Plan hash value: 2807835513 9----------------------------------------------------------------------------------------10| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |11----------------------------------------------------------------------------------------12| 0 | SELECT STATEMENT | | 100 | 397K| 26846 (2)| 00:05:23 |13| 1 | NESTED LOOPS | | 100 | 397K| 26846 (2)| 00:05:23 |14| 2 | TABLE ACCESS FULL| T_20161014_LHR_01 | 100 | 198K| 2 (0)| 00:00:01 |15|* 3 | TABLE ACCESS FULL| T_20161014_LHR_02 | 1 | 2041 | 268 (2)| 00:00:04 |16----------------------------------------------------------------------------------------17Predicate Information (identified by operation id):18---------------------------------------------------19 3 - filter("A"."ID"="B"."ID")20Note21-----22 - dynamic sampling used for this statement (level=2)23Statistics24----------------------------------------------------------25 0 recursive calls26 0 db block gets27 98517 consistent gets28 0 physical reads29 0 redo size30 13950 bytes sent via SQL*Net to client31 586 bytes received via SQL*Net from client32 8 SQL*Net roundtrips to/from client33 0 sorts (memory)34 0 sorts (disk)35 100 rows processed36SYS@lhrdb> SELECT /*+ LEADING(B) USE_NL(A) */ *37 2 FROM T_20161014_LHR_01 A, T_20161014_LHR_02 B38 3 WHERE A.ID = B.ID;39100 rows selected.40Execution Plan41----------------------------------------------------------42Plan hash value: 237512676643----------------------------------------------------------------------------------------44| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |45----------------------------------------------------------------------------------------46| 0 | SELECT STATEMENT | | 100 | 397K| 22939 (2)| 00:04:36 |47| 1 | NESTED LOOPS | | 100 | 397K| 22939 (2)| 00:04:36 |48| 2 | TABLE ACCESS FULL| T_20161014_LHR_02 | 82709 | 160M| 270 (2)| 00:00:04 |49|* 3 | TABLE ACCESS FULL| T_20161014_LHR_01 | 1 | 2028 | 0 (0)| 00:00:01 |50----------------------------------------------------------------------------------------51Predicate Information (identified by operation id):52---------------------------------------------------53 3 - filter("A"."ID"="B"."ID")54Note55-----56 - dynamic sampling used for this statement (level=2)57Statistics58----------------------------------------------------------59 7 recursive calls60 0 db block gets61 301061 consistent gets62 0 physical reads63 0 redo size64 13950 bytes sent via SQL*Net to client65 586 bytes received via SQL*Net from client66 8 SQL*Net roundtrips to/from client67 2 sorts (memory)68 0 sorts (disk)69 100 rows processedSET AUTOT TRACE EXP STAT
2SYS@lhrdb> SELECT /*+ LEADING(A) USE_NL(B) */ *
3 2 FROM T_20161014_LHR_01 A, T_20161014_LHR_02 B
4 3 WHERE A.ID = B.ID;
5100 rows selected.
6Execution Plan
7----------------------------------------------------------
8Plan hash value: 2807835513
9----------------------------------------------------------------------------------------
10| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
11----------------------------------------------------------------------------------------
12| 0 | SELECT STATEMENT | | 100 | 397K| 26846 (2)| 00:05:23 |
13| 1 | NESTED LOOPS | | 100 | 397K| 26846 (2)| 00:05:23 |
14| 2 | TABLE ACCESS FULL| T_20161014_LHR_01 | 100 | 198K| 2 (0)| 00:00:01 |
15|* 3 | TABLE ACCESS FULL| T_20161014_LHR_02 | 1 | 2041 | 268 (2)| 00:00:04 |
16----------------------------------------------------------------------------------------
17Predicate Information (identified by operation id):
18---------------------------------------------------
19 3 - filter("A"."ID"="B"."ID")
20Note
21-----
22 - dynamic sampling used for this statement (level=2)
23Statistics
24----------------------------------------------------------
25 0 recursive calls
26 0 db block gets
27 98517 consistent gets
28 0 physical reads
29 0 redo size
30 13950 bytes sent via SQL*Net to client
31 586 bytes received via SQL*Net from client
32 8 SQL*Net roundtrips to/from client
33 0 sorts (memory)
34 0 sorts (disk)
35 100 rows processed
36SYS@lhrdb> SELECT /*+ LEADING(B) USE_NL(A) */ *
37 2 FROM T_20161014_LHR_01 A, T_20161014_LHR_02 B
38 3 WHERE A.ID = B.ID;
39100 rows selected.
40Execution Plan
41----------------------------------------------------------
42Plan hash value: 2375126766
43----------------------------------------------------------------------------------------
44| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
45----------------------------------------------------------------------------------------
46| 0 | SELECT STATEMENT | | 100 | 397K| 22939 (2)| 00:04:36 |
47| 1 | NESTED LOOPS | | 100 | 397K| 22939 (2)| 00:04:36 |
48| 2 | TABLE ACCESS FULL| T_20161014_LHR_02 | 82709 | 160M| 270 (2)| 00:00:04 |
49|* 3 | TABLE ACCESS FULL| T_20161014_LHR_01 | 1 | 2028 | 0 (0)| 00:00:01 |
50----------------------------------------------------------------------------------------
51Predicate Information (identified by operation id):
52---------------------------------------------------
53 3 - filter("A"."ID"="B"."ID")
54Note
55-----
56 - dynamic sampling used for this statement (level=2)
57Statistics
58----------------------------------------------------------
59 7 recursive calls
60 0 db block gets
61 301061 consistent gets
62 0 physical reads
63 0 redo size
64 13950 bytes sent via SQL*Net to client
65 586 bytes received via SQL*Net from client
66 8 SQL*Net roundtrips to/from client
67 2 sorts (memory)
68 0 sorts (disk)
69 100 rows processed可以看出，用T_20161014_LHR_01（小表）做驱动表的时候，逻辑读为98517，而用T_20161014_LHR_02（大表）做驱动表的时候，逻辑读为301061，差异非常大，所以，在使用NL连接的时候，尽量选择结果集较小的表作为驱动表。
（三）哈希连接（HJ）
HJ的连接原理如下：首先把小表的哈希操作存放到内存中，然后用大表的每条记录做哈希，与之前小表的哈希值匹配。这种连接是在Oracle 7.3引入的，从理论上来说比NL与SMJ更高效，而且只用在CBO（Cost Based Optimization，基于代价的优化器）优化器中。
哈希连接的连接过程如下所示：
（1）构建阶段：优化器首先选择一张小表作为驱动表，运用哈希函数对连接列进行计算产生一张哈希表。通常这个步骤是在内存（HASH_AREA_SIZE）中进行的，所以，运算很快。
（2）探测阶段：优化器对被驱动表的连接列运用同样的哈希函数计算得到的结果与前面形成的哈希表进行探测返回符合条件的记录。这个阶段中如果被驱动表的连接列的值没有与驱动表连接列的值相等的话，那么这些记录将会被丢弃而不进行探测。
这种方式适用于较小的表完全可以放于内存中的情况，这样总成本就是访问两个表的成本之和。在表很大的情况下并不能完全放入内存，这时优化器会将它分割成若干不同的分区，不能放入内存的部分就把该分区写入磁盘的临时段，此时要有较大的临时段从而尽量提高I/O的性能。HJ也适用于两个大表的关联。
哈希连接也可以用USE_HASH(T1 T2)提示来强制使用。如果使用哈希连接，那么初始化参数HASH_AREA_SIZE必须足够的大，如果是Oracle 9i以上版本，那么Oracle建议使用SQL工作区自动管理，设置WORKAREA_SIZE_POLICY为AUTO，然后调整PGA_AGGREGATE_TARGET的大小即可。
在Oracle数据库中有一个隐含参数“_HASH_JOIN_ENABLED”控制着HJ的启用和关闭，该参数默认值是TRUE，表示启用HJ连接。
可以借助于10104事件所产生的trace文件来观察目标SQL在做哈希连接时的大致过程和一些统计信息（比如用了多少个Hash Partition、多少个Hash Bucket以及各个Hash Bucket都分别有多少条记录等），10104事件在实际诊断哈希连接的性能问题时非常有用。
1[root@rhel6lhr ~]# oerr ora 10104210104, 00000, "dump hash join statistics to trace file"# oerr ora 10104 210104, 00000, "dump hash join statistics to trace file"
使用10104事件观察目标SQL做哈希连接的具体过程为：
1oradebug setmypid2oradebug event 10104 trace name context forever, level 13set autotrace traceonly4实际执行目标SQL（必须要实际执行该SQL，不能用explain plan for）5oradebug tracefile_name 2oradebug event 10104 trace name context forever, level 1 3set autotrace traceonly 4实际执行目标SQL（必须要实际执行该SQL，不能用explain plan for） 5oradebug tracefile_name
HJ的连接方式示例如下所示：
1SYS@lhrdb> SET AUTOT TRACE EXP STAT 2SYS@lhrdb> SELECT /*+ leading(A) use_hash(B) */ * 3 2 FROM T_20161014_LHR_01 A, T_20161014_LHR_02 B 4 3 WHERE A.ID = B.ID; 5100 rows selected. 6Execution Plan 7---------------------------------------------------------- 8Plan hash value: 35977193 9----------------------------------------------------------------------------------------10| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |11----------------------------------------------------------------------------------------12| 0 | SELECT STATEMENT | | 100 | 397K| 273 (2)| 00:00:04 |13|* 1 | HASH JOIN | | 100 | 397K| 273 (2)| 00:00:04 |14| 2 | TABLE ACCESS FULL| T_20161014_LHR_01 | 100 | 198K| 2 (0)| 00:00:01 |15| 3 | TABLE ACCESS FULL| T_20161014_LHR_02 | 82709 | 160M| 270 (2)| 00:00:04 |16----------------------------------------------------------------------------------------17Predicate Information (identified by operation id):18---------------------------------------------------19 1 - access("A"."ID"="B"."ID")20Note21-----22 - dynamic sampling used for this statement (level=2)23Statistics24----------------------------------------------------------25 7 recursive calls26 0 db block gets27 1057 consistent gets28 0 physical reads29 0 redo size30 13950 bytes sent via SQL*Net to client31 586 bytes received via SQL*Net from client32 8 SQL*Net roundtrips to/from client33 2 sorts (memory)34 0 sorts (disk)35 100 rows processedSET AUTOT TRACE EXP STAT
2SYS@lhrdb> SELECT /*+ leading(A) use_hash(B) */ *
3 2 FROM T_20161014_LHR_01 A, T_20161014_LHR_02 B
4 3 WHERE A.ID = B.ID;
5100 rows selected.
6Execution Plan
7----------------------------------------------------------
8Plan hash value: 35977193
9----------------------------------------------------------------------------------------
10| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
11----------------------------------------------------------------------------------------
12| 0 | SELECT STATEMENT | | 100 | 397K| 273 (2)| 00:00:04 |
13|* 1 | HASH JOIN | | 100 | 397K| 273 (2)| 00:00:04 |
14| 2 | TABLE ACCESS FULL| T_20161014_LHR_01 | 100 | 198K| 2 (0)| 00:00:01 |
15| 3 | TABLE ACCESS FULL| T_20161014_LHR_02 | 82709 | 160M| 270 (2)| 00:00:04 |
16----------------------------------------------------------------------------------------
17Predicate Information (identified by operation id):
18---------------------------------------------------
19 1 - access("A"."ID"="B"."ID")
20Note
21-----
22 - dynamic sampling used for this statement (level=2)
23Statistics
24----------------------------------------------------------
25 7 recursive calls
26 0 db block gets
27 1057 consistent gets
28 0 physical reads
29 0 redo size
30 13950 bytes sent via SQL*Net to client
31 586 bytes received via SQL*Net from client
32 8 SQL*Net roundtrips to/from client
33 2 sorts (memory)
34 0 sorts (disk)
35 100 rows processed（四）笛卡尔积（MJC）
笛卡尔积不能算真正的连接方式。一般来讲，对于一个做笛卡尔积的SQL，要不是因为SQL的写法不正确（做MERGE JOIN的两张表没有关联条件），就是因为Oracle没有正确地收集表的统计信息从而导致生成了错误的执行计划，可以通过如下方式来解决：
① 对形成MJC的2个表进行表分析，收集正确的统计信息。
② 加/*+ OPT_PARAM('_OPTIMIZER_MJC_ENABLED' 'FALSE') */的Hint来限制SQL进行MJC的连接。
③ 对形成MJC的2个表加上有效的连接条件。
隐含参数“_OPTIMIZER_MJC_ENABLED”控制着MJC的启用和关闭，该参数默认值是TRUE，表示启用MJC连接。
MJC的连接方式示例如下所示：
1SYS@lhrdb> SET AUTOT TRACE EXP STAT 2SYS@lhrdb> SELECT * 3 2 FROM T_20161014_LHR_01 A, T_20161014_LHR_02 B 4 3 ; 510000000 rows selected. 6Execution Plan 7---------------------------------------------------------- 8Plan hash value: 337631975 9------------------------------------------------------------------------------------------10| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |11------------------------------------------------------------------------------------------12| 0 | SELECT STATEMENT | | 8270K| 31G| 22939 (2)| 00:04:36 |13| 1 | MERGE JOIN CARTESIAN| | 8270K| 31G| 22939 (2)| 00:04:36 |14| 2 | TABLE ACCESS FULL | T_20161014_LHR_02 | 82709 | 160M| 270 (2)| 00:00:04 |15| 3 | BUFFER SORT | | 100 | 198K| 22669 (2)| 00:04:33 |16| 4 | TABLE ACCESS FULL | T_20161014_LHR_01 | 100 | 198K| 0 (0)| 00:00:01 |17------------------------------------------------------------------------------------------18Note19-----20 - dynamic sampling used for this statement (level=2)21Statistics22----------------------------------------------------------23 9 recursive calls24 0 db block gets25 100071 consistent gets26 0 physical reads27 0 redo size28 748567590 bytes sent via SQL*Net to client29 7333846 bytes received via SQL*Net from client30 666668 SQL*Net roundtrips to/from client31 1 sorts (memory)32 0 sorts (disk)33 10000000 rows processedSET AUTOT TRACE EXP STAT 2SYS@lhrdb> SELECT * 3 2 FROM T_20161014_LHR_01 A, T_20161014_LHR_02 B 4 3 ; 510000000 rows selected. 6Execution Plan 7---------------------------------------------------------- 8Plan hash value: 337631975 9------------------------------------------------------------------------------------------ 10| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 11------------------------------------------------------------------------------------------ 12| 0 | SELECT STATEMENT | | 8270K| 31G| 22939 (2)| 00:04:36 | 13| 1 | MERGE JOIN CARTESIAN| | 8270K| 31G| 22939 (2)| 00:04:36 | 14| 2 | TABLE ACCESS FULL | T_20161014_LHR_02 | 82709 | 160M| 270 (2)| 00:00:04 | 15| 3 | BUFFER SORT | | 100 | 198K| 22669 (2)| 00:04:33 | 16| 4 | TABLE ACCESS FULL | T_20161014_LHR_01 | 100 | 198K| 0 (0)| 00:00:01 | 17------------------------------------------------------------------------------------------ 18Note 19----- 20 - dynamic sampling used for this statement (level=2) 21Statistics 22---------------------------------------------------------- 23 9 recursive calls 24 0 db block gets 25 100071 consistent gets 26 0 physical reads 27 0 redo size 28 748567590 bytes sent via SQL*Net to client 29 7333846 bytes received via SQL*Net from client 30 666668 SQL*Net roundtrips to/from client 31 1 sorts (memory) 32 0 sorts (disk) 33 10000000 rows processed
可以看到，MJC的连接方式是非常耗费性能的，在生产库上尤其得避免这种连接方式。
（五）总结
HJ、SMJ和NL连接随着数据量的增加，其连接速度可以简单地表示成下图所示样子：
对于DBA来说，掌握这3种表的连接方式可以对SQL优化起到至关重要的作用。对于这3种关联方式的详细对比，参考下表：
