HASH JOIN ,MERGE JOIN ,NESTED LOOP用法效率比较

最新推荐文章于 2024-04-01 09:07:54 发布
最新推荐文章于 2024-04-01 09:07:54 发布
阅读量1.3w 收藏 18
点赞数 3
分类专栏： Oracle 优化 文章标签： join JOIN oracle优化
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lichangzai/article/details/8332957
版权

概述：

NESTED LOOP:

对于被连接的数据子集较小的情况，嵌套循环连接是个较好的选择。在嵌套循环中，内表被外表驱动，外表返回的每一行都要在内表中检索找到与它匹配的行，因此整个查询返回的结果集不能太大（大于1 万不适合），要把返回子集较小表的作为外表（CBO 默认外表是驱动表），而且在内表的连接字段上一定要有索引。当然也可以用ORDERED 提示来改变CBO默认的驱动表，使用USE_NL(table_name1 table_name2)可是强制CBO 执行嵌套循环连接。

 

HASH JOIN :

散列连接是CBO 做大数据集连接时的常用方式，优化器使用两个表中较小的表（或数据源）利用连接键在内存中建立散列表，然后扫描较大的表并探测散列表，找出与散列表匹配的行。

这种方式适用于较小的表完全可以放于内存中的情况，这样总成本就是访问两个表的成本之和。但是在表很大的情况下并不能完全放入内存，这时优化器会将它分割成若干不同的分区，不能放入内存的部分就把该分区写入磁盘的临时段，此时要有较大的临时段从而尽量提高I/O 的性能。

也可以用USE_HASH(table_name1 table_name2)提示来强制使用散列连接。如果使用散列连接HASH_AREA_SIZE 初始化参数必须足够的大，如果是9i，Oracle建议使用SQL工作区自动管理，设置WORKAREA_SIZE_POLICY 为AUTO，然后调整PGA_AGGREGATE_TARGET 即可。

 

MERGE JOIN排序合并连接

通常情况下散列连接的效果都比排序合并连接要好，然而如果行源已经被排过序，在执行排序合并连接时不需要再排序了，这时排序合并连接的性能会优于散列连接。可以使用USE_MERGE(table_name1 table_name2)来强制使用排序合并连接

 

几种方式的操作方式

merge join

merge join的操作通常分三步：

1、对连接的每个表做table access full;

2、对table access full的结果进行排序。

3、进行merge join对排序结果进行合并。

在全表扫描比索引范围扫描再通过rowid进行表访问更可取的情况下，merge join会比nested loops性能更佳。当表特别小或特别巨大的时候，实行全表访问可能会比索引范围扫描更有效。mrege join的性能开销几乎都在前两步。

 

hash join

对两个表进行全表扫描，然后oracle读取涉及连接的其中一个表，并且在内存里创建来自表的连接列的唯一关键字的位图。当读取和处理第二个表的行时，创建值的位图被用做过滤器。如果一个行成功的通过位图过滤，则hash算法用于数据查找和后来的连接。（这里涉及数学问题，我也弄的不是很清楚）。

以下条件下hash join可能有优势：

两个巨大的表之间的连接。

在一个巨大的表和一个小表之间的连接。

 

Nested Loops

会循环外表（驱动表），逐个比对和内表的连接是否符合条件。在驱动表比较小，内表比较大，而且内外表的连接列有索引的时候比较好。当SORT_AREA空间不足的时候，Oracle也会选择使用NL。基于Cost的Oracle优化器(CBO)会自动选择较小的表做外表。

 

 

连接方式总结：

1)）嵌套循环(nest loop):

          对于被连接的数据子集较小的情况，嵌套循环连接是较好的选择。在嵌套循环中，外表驱动内表，外表返回的每一行都要在内表中检索找到它匹配的行，因此整个查询返回的结果集不能太大（大于10000不合适），要把返回子集较小的表作为外表（驱动表），而且在内表的连接字段上一定要有索引。

2）哈希连接(hash join):

         哈希连接是大数据集连接时常用的方式，优化器使用两个表中较小的表，利用连接键在内存中建立散列表，然后扫描较大的表并探测散列表，找出与散列表匹配的行。

        这种方式适用于较小的表完全可以放入内存的情况，这样成本就是访问两个表的成本之和。但是在表很大的情况下并不能完全放入内存，这时优化器将它分割成若干不同的分区，不能放入内存的部分就把该分区写入磁盘的临时段。

        哈希连接只能应用于等值连接(如WHERE A.COL3 = B.COL4)、非等值连接(WHERE A.COL3 > B.COL4)、外连接(WHERE A.COL3 = B.COL4(+))。

3）排序合并连接（Sort Merge Join ）

          通常情况下哈希连接的效果都比排序合并连接要好。然而如果行源已经被排过序，在执行排序合并连接时不需要再排序了，这时排序归并连接的性能会忧于哈希连接。

 

测试实验：

 

--创建测试表

SQL> Create Table t As Select * From dba_objects;
SQL> Insert /*+ append*/ t Select * From t;
SQL> Insert /*+ append*/ t Select * From t;
......
SQL> commit;

SQL> Create Table t1 As Select * From user_objects;

SQL> Create Table t2 As Select * From dba_objects;
SQL> Insert /*+ append*/ t2 Select * From t2;
......
SQL> commit;

SQL> select count(1) from t;

  COUNT(1)
----------
   3199936

SQL> select count(1) from t2;

  COUNT(1)
----------
    101220

SQL> select count(1) from t1;

  COUNT(1)
----------
        13
       
SQL> Create Index ind_id On t(object_id);
SQL> Create Index ind1_id On t1(object_id);
SQL> Create Index ind2_id On t2(object_id);


1.默认使用Nested loops的SQL语句的情况
--不加hints会默认使用Nested loops join
SQL> Select * From t,t1 Where t.object_id=t1.object_id;

576 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 1308275697

--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |   833 |   208K|   862   (1)| 00:00:11 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T      |    64 |  6144 |    66   (0)| 00:00:01 |
|   2 |   NESTED LOOPS              |        |   833 |   208K|   862   (1)| 00:00:11 |
|   3 |    TABLE ACCESS FULL        | T1     |    13 |  2080 |     3   (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN         | IND_ID |    64 |       |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("T"."OBJECT_ID"="T1"."OBJECT_ID")

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          5  recursive calls
          0  db block gets
        687  consistent gets
          0  physical reads
       1484  redo size
      14877  bytes sent via SQL*Net to client
        910  bytes received via SQL*Net from client
         40  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
        576  rows processed

--强制使用Hash Jion
SQL> Select /*+ use_hash(t1,t)*/ * From t1,t Where t.object_id=t1.object_id;

576 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 1444793974

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |   833 |   208K|  9931   (3)| 00:02:00 |
|*  1 |  HASH JOIN         |      |   833 |   208K|  9931   (3)| 00:02:00 |
|   2 |   TABLE ACCESS FULL| T1   |    13 |  2080 |     3   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| T    |  3204K|   293M|  9890   (2)| 00:01:59 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("T"."OBJECT_ID"="T1"."OBJECT_ID")

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          4  recursive calls
          0  db block gets
      44124  consistent gets
          0  physical reads
        524  redo size
      71981  bytes sent via SQL*Net to client
        910  bytes received via SQL*Net from client
         40  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
        576  rows processed


--强制使用Merge join
SQL> Select /*+ use_merge(t1,t)*/ * From t1,t Where t.object_id=t1.object_id;

576 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2036048135

------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name    | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |         |   833 |   208K|       | 80548   (1)| 00:16:07 |
|   1 |  MERGE JOIN                  |         |   833 |   208K|       | 80548   (1)| 00:16:07 |
|   2 |   TABLE ACCESS BY INDEX ROWID| T1      |    13 |  2080 |       |     2   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | IND1_ID |    13 |       |       |     1   (0)| 00:00:01 |
|*  4 |   SORT JOIN                  |         |  3204K|   293M|   794M| 80546   (1)| 00:16:07 |
|   5 |    TABLE ACCESS FULL         | T       |  3204K|   293M|       |  9890   (2)| 00:01:59 |
------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("T"."OBJECT_ID"="T1"."OBJECT_ID")
       filter("T"."OBJECT_ID"="T1"."OBJECT_ID")

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      44097  consistent gets
          0  physical reads
        524  redo size
      14899  bytes sent via SQL*Net to client
        910  bytes received via SQL*Net from client
         40  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
        576  rows processed

结论：
逻辑读分别为：
Nested loops join 687
Hash Jion 44124
Merge join 44097
可以看到，大表t和小表t1关联使用Nested loops join关联性能会比较好。

2.默认使用Hash Jion的SQL语句的情况

--不加hints会默认使用Hash Jion
SQL> set timing on
SQL> Select  t.object_id From t,t2 Where t.object_id=t2.object_id;

6364032 rows selected.

Elapsed: 00:00:31.58

Execution Plan
----------------------------------------------------------
Plan hash value: 3237705646

-----------------------------------------------------------------------------------------
| Id  | Operation             | Name    | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |         |  5713K|    98M|       |  4442   (4)| 00:00:54 |
|*  1 |  HASH JOIN            |         |  5713K|    98M|  2224K|  4442   (4)| 00:00:54 |
|   2 |   INDEX FAST FULL SCAN| IND2_ID | 90908 |  1154K|       |    55   (4)| 00:00:01 |
|   3 |   INDEX FAST FULL SCAN| IND_ID  |  3204K|    15M|       |  1596   (4)| 00:00:20 |
-----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("T"."OBJECT_ID"="T2"."OBJECT_ID")

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          4  recursive calls
          0  db block gets
     430719  consistent gets
          0  physical reads
          0  redo size
  109700403  bytes sent via SQL*Net to client
    4667440  bytes received via SQL*Net from client
     424270  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
    6364032  rows processed

--强制使用Nested loops join
SQL> Select  /*+ use_nl(t,t2)*/ t.object_id From t,t2 Where t.object_id=t2.object_id;

6364032 rows selected.

Elapsed: 00:00:31.45

Execution Plan
----------------------------------------------------------
Plan hash value: 3551542035

---------------------------------------------------------------------------------
| Id  | Operation             | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |         |  5713K|    98M| 98323   (1)| 00:19:40 |
|   1 |  NESTED LOOPS         |         |  5713K|    98M| 98323   (1)| 00:19:40 |
|   2 |   INDEX FAST FULL SCAN| IND2_ID | 90908 |  1154K|    55   (4)| 00:00:01 |
|*  3 |   INDEX RANGE SCAN    | IND_ID  |    63 |   315 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("T"."OBJECT_ID"="T2"."OBJECT_ID")

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          4  recursive calls
          0  db block gets
     838760  consistent gets
          0  physical reads
          0  redo size
  109700403  bytes sent via SQL*Net to client
    4667440  bytes received via SQL*Net from client
     424270  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
    6364032  rows processed
   
--强制使用merge join
SQL> Select  /*+ use_merge(t,t2)*/ t.object_id From t,t2 Where t.object_id=t2.object_id;

6364032 rows selected.

Elapsed: 00:00:31.78

Execution Plan
----------------------------------------------------------
Plan hash value: 1712472574

------------------------------------------------------------------------------------------
| Id  | Operation              | Name    | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |         |  5713K|    98M|       |  7661   (2)| 00:01:32 |
|   1 |  MERGE JOIN            |         |  5713K|    98M|       |  7661   (2)| 00:01:32 |
|   2 |   INDEX FULL SCAN      | IND_ID  |  3204K|    15M|       |  7137   (2)| 00:01:26 |
|*  3 |   SORT JOIN            |         | 90908 |  1154K|  3576K|   495   (3)| 00:00:06 |
|   4 |    INDEX FAST FULL SCAN| IND2_ID | 90908 |  1154K|       |    55   (4)| 00:00:01 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("T"."OBJECT_ID"="T2"."OBJECT_ID")
       filter("T"."OBJECT_ID"="T2"."OBJECT_ID")

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          4  recursive calls
          0  db block gets
     430689  consistent gets
          0  physical reads
          0  redo size
  109700403  bytes sent via SQL*Net to client
    4667440  bytes received via SQL*Net from client
     424270  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
    6364032  rows processed
   
结论：
逻辑读分别为：
Nested loops join 838760
Hash Jion 430719
Merge join 430689
可以看到，大表t和大表t2关联使用Hash Jion和Merge join关联性能差不多，Nested loops join性能最差。

3.默认使用Merge Jion的SQL语句的情况
--不加hints会默认使用Merge Jion
SQL> Select  t.object_id From t2,(Select * From t Where owner='SYS' Order By object_id) t Where t.object_id=t2.object_id;

2910592 rows selected.

Elapsed: 00:00:15.57

Execution Plan
----------------------------------------------------------
Plan hash value: 2780935651

---------------------------------------------------------------------------------------
| Id  | Operation           | Name    | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |         |  2589K|    59M|       | 16553   (2)| 00:03:19 |
|   1 |  MERGE JOIN         |         |  2589K|    59M|       | 16553   (2)| 00:03:19 |
|   2 |   INDEX FULL SCAN   | IND2_ID | 90908 |  1154K|       |   240   (2)| 00:00:03 |
|*  3 |   SORT JOIN         |         |  1452K|    15M|    55M| 16300   (2)| 00:03:16 |
|*  4 |    TABLE ACCESS FULL| T       |  1452K|    15M|       |  9822   (2)| 00:01:58 |
---------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("T"."OBJECT_ID"="T2"."OBJECT_ID")
       filter("T"."OBJECT_ID"="T2"."OBJECT_ID")
   4 - filter("OWNER"='SYS')

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          4  recursive calls
          0  db block gets
      89745  consistent gets
          0  physical reads
        124  redo size
   50169586  bytes sent via SQL*Net to client
    2134921  bytes received via SQL*Net from client
     194041  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
    2910592  rows processed
   
--强制使用Nested join
SQL> Select  /*+ use_nl(t2,t)*/  t.object_id From t2,(Select * From t Where owner='SYS' Order By object_id) t Where t.object_id=t2.object_id;

2910592 rows selected.

Elapsed: 00:00:17.18

Execution Plan
----------------------------------------------------------
Plan hash value: 1858129701

---------------------------------------------------------------------------------------
| Id  | Operation           | Name    | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |         |  2589K|    59M|       |  1482K  (1)| 04:56:28 |
|   1 |  SORT ORDER BY      |         |  2589K|    59M|    79M|  1482K  (1)| 04:56:28 |
|   2 |   NESTED LOOPS      |         |  2589K|    59M|       |  1463K  (1)| 04:52:47 |
|*  3 |    TABLE ACCESS FULL| T       |  1452K|    15M|       |  9822   (2)| 00:01:58 |
|*  4 |    INDEX RANGE SCAN | IND2_ID |     2 |    26 |       |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("OWNER"='SYS')
   4 - access("T"."OBJECT_ID"="T2"."OBJECT_ID")

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          4  recursive calls
          0  db block gets
    1523249  consistent gets
          0  physical reads
        568  redo size
   50169586  bytes sent via SQL*Net to client
    2134921  bytes received via SQL*Net from client
     194041  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
    2910592  rows processed

--强制使用Hash join
SQL> Select  /*+ use_hash(t2,t)*/  t.object_id From t2,(Select * From t Where owner='SYS' Order By object_id) t Where t.object_id=t2.object_id;

2910592 rows selected.

Elapsed: 00:00:16.34

Execution Plan
----------------------------------------------------------
Plan hash value: 2900034259

------------------------------------------------------------------------------------------
| Id  | Operation              | Name    | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |         |  2589K|    59M|       | 30029   (2)| 00:06:01 |
|   1 |  SORT ORDER BY         |         |  2589K|    59M|    79M| 30029   (2)| 00:06:01 |
|*  2 |   HASH JOIN            |         |  2589K|    59M|  2224K| 11615   (2)| 00:02:20 |
|   3 |    INDEX FAST FULL SCAN| IND2_ID | 90908 |  1154K|       |    55   (4)| 00:00:01 |
|*  4 |    TABLE ACCESS FULL   | T       |  1452K|    15M|       |  9822   (2)| 00:01:58 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("T"."OBJECT_ID"="T2"."OBJECT_ID")
   4 - filter("OWNER"='SYS')

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          4  recursive calls
          0  db block gets
      44373  consistent gets
          0  physical reads
        524  redo size
   50169586  bytes sent via SQL*Net to client
    2134921  bytes received via SQL*Net from client
     194041  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
    2910592  rows processed
   
结论：
逻辑读分别为：
Nested loops join 1523249
Hash Jion 44373
Merge join 89745
可以看到，T2在和t的排序的限定结果集关联时，执行计划使用了merge join，但此时执行效率最的还是hash join，因为此时同样是大表之间关联，采用hash join效果会更好一些。

常飞梦
关注
  • 3
    点赞
  • 踩
  • 18
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
MySQL中Nested-Loop Join算法小结
09-10
数据库中JOIN操作的实现主要有三种：嵌套循环连接（Nested Loop Join），归并连接（Merge Join）和散列连接或者哈稀连接（Hash Join）。其中嵌套循环连接又视情况又有两种变形：块嵌套循环连接和索引嵌套循环连接。
oracle join速度慢,oracle中三种join方法的比较
weixin_35242523的博客
04-03 1283
一.三种join方法的定义及适用情况1.Nested loop join:outer table中的每一行与inner table中的相应记录join,类似一个嵌套的循环。适用于outer table(有的地方叫master table)的记录集比较少(<10000)而且inner table(有的地方叫Detail table)索引选择性较好的情况下(inner table要有index)...
ob优化之：Merge Join
最新发布
viviliving的专栏
04-01 18
Merge Join 其实是 Nested Loops Joins 的一种变种。如果连接的两个数据集尚未排序，则数据库会对它们进行排序。对于第一个数据集中的每一行，数据库会探测第二个数据集中的匹配行并将它们连接起来，其起始位置基于上一次迭代中的匹配。这一点与 Nested Loops Joins 不同，Nested Loops Joins 遍历第二个数据集时每次都是从第一行数据开始。Merge Join 的执行伪代码如下所示。
Nested Loop Join
chongzongqiao2389的博客
09-06 259
我们都知道SQL的join关联表的使用方式，但是这次聊的是实现join的算法，join有三种算法，分别是Nested Loop Join，Hash join，Sort Merge Join。 MySQL官方文档中提到，MySQL只支持Nested Loop Join这一种join algor...
sql hash join VS nested loop
bjchangxiao的专栏
03-22 214
 最近看了Expert Oracle SQL Optimization,Deployment, and Statistics这本书，其中介绍了hash join的优缺点，这里做个笔记。 Hash joins have the following advantages over nested loops when the probe row source is a table: •Ever
Merge join、Hash join、Nested loop join对比分析
热门推荐
开平人生
11-16 1万+
SQL server 内部实现了三种类型的内连接运算，大多数人从来没有听说过这些连接类型，因为它们不是逻辑连接也很少被用于代码中。那么它们什么时候会被用到呢？答案是要依情况而定。这就意味着要依赖于记录集和索引。查询优化器总是智能的选择最优的物理连接类型。我们知道SQL优化器创建一个计划开销是基于查询开销的，并依据此来选择最佳连接类型。         那查询优化器究竟是怎样从内部选择连接类型的呢
HASH JOIN ,MERGE JOIN ,NESTED LOOP
cufen6148的博客
04-09 143
NESTED LOOP:对于被连接的数据子集较小的情况，嵌套循环连接是个较好的选择。在嵌套循环中，内表被外表驱动，外表返回的每一行都要在内表中检索找到与它匹配的行，因此整个查询返回的结果集不能太大（大于1 万不适合），要把返回子...
oracle 主键关联 效率,Hash join与nested loops join的效率比较
weixin_35710880的博客
04-04 430
创建测试表SQL> create table t as select rownum id from dba_objects;Table created.SQL> create index idx_t on t(id);Index created.SQL> exec dbms_stats.gather_table_stats('sys','t',cascade=>true);...
HASH JOIN 跟NESTED LOOP 快一个列子
jinghuainfo
05-06 63
在报表库的每个小时数据量23113条时候 NESTED LOOP 要跑3分钟 而 HASH JOIN 才7秒钟 NESTED LOOP: SELECT * FROM ( SELECT ACTIONID, OPCONTENTID, MOUDULEID, PORTALID, 'lars01.OP_MAIL_VISIT_04_1105' AS table_name, T...
Hash join与nested loops join的效率比较
weixin_34417183的博客
10-14 463
创建测试表SQL> create table t as select rownum id from dba_objects;Table created.SQL> create index idx_t on t(id);Index created.SQL> exec dbms_stats.gather_table_stats('sys','t',cascade...
Mysql 8.0.18 hash join测试(推荐)
09-09
给大家介绍Mysql 8.0.18 hash join测试的相关知识，本文通过实例代码讲解，非常不错，具有一定的参考借鉴价值，需要的朋友参考下吧
MySQL 8.0.18 Hash Join不支持left/right join左右连接问题
01-19
在MySQL 8.0.18中，增加了Hash Join新功能，它适用于未创建索引的字段，...我们用explain format=tree命令可以查看到已经使用到hash join算法。 但目前8.0.18版本，仅支持join。left join和right join失效，这里请注意
MySQL 8.0 新特性之哈希连接（Hash Join）
09-09
MySQL 开发组于 2019 年 10 月 14 日 正式发布了 MySQL 8.0.18 GA 版本，带来了一些新特性和增强功能。这篇文章主要介绍了MySQL 8.0 新特性之哈希连接（Hash Join）,需要的朋友可以参考下
比较全文索引和传统的模糊查询的性能
我思，故我在！--My data life
01-06 5596
--查看表数据的内容和分布 SQL> select count(*) from members;     COUNT(*) ----------     345567   SQL> CREATE INDEX ct_ind ON members(member_name) INDEXTYPE IS CTXSYS.CONTEXT; 索引已创建。 实验1:全文索引性能差于模糊查
SQL优化一则：灵活运用字段的选择性
我思，故我在！--My data life
03-18 3012
概念： 优化策略：字段选择性 选择性较低索引 可能带来的性能问题索引选择性=索引列唯一值/表记录数；选择性越高索引检索价值越高，消耗系统资源越少；选择性越低索引检索价值越低，消耗系统资源越多；查询条件含有多个字段时，不要在选择性很低字段上创建索引可通过创建组合索引来增强低字段选择性和避免选择性很低字段创建索引带来副作用；尽量减少possible_keys，正确索引会提高sql查询速度，过多索引
oracle几个优化有用的视图
我思，故我在！--My data life
01-25 2446
目的：不要死记硬背script，深入理解view的含义，才能自如运用它们。 包括：V$SYSTEM_EVENT/ V$SESSION_EVENT/ V$SESSION_WAIT / V$WAITSTAT http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/sqlviews.htm#17389 V$SYST
SQL优化一则：CBO查询SQL一次比一次慢
我思，故我在！--My data life
12-20 1777
问题： 今天在开发的新上线一个功能后，下面SQL消耗了大量的CPU，数据库处一度处于满负荷进行，使用率达到100%.赶紧kill掉了正进行的SQL，以免对其它业务产生影响。 通过测试，发现一个很奇怪的问题，SQL在第一次执行时会很快，在连续执行几次后，一次比一次的慢。 甚至到最后一直挂起在那，产生等待。当停掉后，过会（10分钟左右）再执行，第一次又会变快，如果再连接执行几次，又会出现同样的慢
oracle Text 全文检索功能对中文分词的支持情况
我思，故我在！--My data life
01-06 1652
下面例子在XE中测试通过。 准备工作： CREATE   TABLE issues (     ID         NUMBER,     summary       VARCHAR(120),     description   CLOB,     author     VARCHAR(80),     ot_version VARCHAR(10) ); IN
试举出 3 个自然连接的例子，分别使用 nested loop、hash join、sort merge 来进行连接 （展示其执行计划）。提示：可以使用 hints
06-03
例子1：使用 nested loop 进行自然连接 ``` SELECT * FROM orders, customers WHERE orders.customer_id = customers.customer_id; ``` 执行计划： ``` -------------------------------------------------------...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值