13518219792
测试sort merge join
成都创新互联公司是一家专业从事网站设计、做网站的网络公司。作为专业网络公司,成都创新互联公司依托的技术实力、以及多年的网站运营经验,为您提供专业的成都网站建设、全网整合营销推广及网站设计开发服务！
When the Optimizer Considers Sort Merge Joins
A hash join requires one hash table and one probe of this table, whereas a sort merge join requires two sorts.
The optimizer may choose a sort merge join over a hash join for joining large amounts of data when any of the following conditions is true:
The join condition between two tables is not an equijoin, that is, uses an inequality condition such as <, <=, >, or >=.
In contrast to sort merges, hash joins require an equality condition.
Because of sorts required by other operations, the optimizer finds it cheaper to use a sort merge.
If an index exists, then the database can avoid sorting the first data set. However, the database always sorts the second data set, regardless of indexes.SQL> create table t1 (id number);
Table created.
SQL> create table t2 (id number);
Table created.
SQL> insert into t1 values(2);
1 row created.
SQL> insert into t1 values(1);
1 row created.
SQL> insert into t1 values(5);
1 row created.
SQL> insert into t1 values(3);
1 row created.
SQL> commit;
SQL> select * from t1;
ID
----------
2
1
5
3
SQL> insert into t2 values(11);
1 row created.
SQL> insert into t2 values(9);
1 row created.
SQL> insert into t2 values(1);
1 row created.
SQL> commit;
SQL> select * from t2;
ID
----------
11
9
1
SQL>
SQL> exec dbms_stats.gather_table_stats('SYS','T1');
PL/SQL procedure successfully completed.
SQL> exec dbms_stats.gather_table_stats('SYS','T2');
PL/SQL procedure successfully completed.
SQL> set autot off
SQL> create index ind_id on t1(Id);
Index created.
SQL> set autot traceonly
SQL> select * from t1,t2 where t1.id>t2.id;
Execution Plan
----------------------------------------------------------
Plan hash value: 1335671014
------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 12 | 4 (25)| 00:00:01 |
| 1 | MERGE JOIN | | 2 | 12 | 4 (25)| 00:00:01 |
| 2 | SORT JOIN | | 4 | 12 | 1 (0)| 00:00:01 |
| 3 | INDEX FULL SCAN | IND_ID | 4 | 12 | 1 (0)| 00:00:01 |
|* 4 | SORT JOIN | | 3 | 9 | 3 (34)| 00:00:01 |
| 5 | TABLE ACCESS FULL| T2 | 3 | 9 | 2 (0)| 00:00:01 |
------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access(INTERNAL_FUNCTION("T1"."ID")>INTERNAL_FUNCTION("T2"."ID"))
filter(INTERNAL_FUNCTION("T1"."ID")>INTERNAL_FUNCTION("T2"."ID"))
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
652 bytes sent via SQL*Net to client
519 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
3 rows processed
