甲说:
A B两个表总数据量都很大,在百万以上。
idx1 idx2字段表示是索引字段
A B 两表上都有
col1字段表示普通字段
select xxx from A
where A.idx1 between mmm and nnn
and exists (select 1 from B where B.idx2 = A.col1)
满足A.idx1 between mmm and nnn条件的行一般是几百到几千行,选择性还可以。B表上idx2字段选择性很高。
以前执行计划是 NESTED LOOP-SEMI-JOIN,效率很高。
今天数据库负载突增,最后发现是该语句的执行计划变成 HASH JOIN-SEMI-JOIN,也就意味着对B表进行table access full!
无奈之下,修改查询语句为
... and exists (select /*+ NL_SJ */ 1 from B where...
哪位能指点一下为什么执行计划会变得极差?
乙说:从新分析一下表在查询看看
甲说:
这是未加提示的语句及执行计划,走了HASH JOIN SEMI。[/COLOR]
[PHP]
SQL> explain plan for
2 select count(*)
3 from RECORD_TEMP_A t
4 where 1 = 1
5 and t.datsendtime >= sysdate - 20
6 and t.datsendtime < sysdate - 10
7 AND EXISTS (SELECT 1
8 FROM RECORD_TEMP_B partition(P_MAXVALUE) V
9 WHERE V.MSGID = T.MSGID);
已解释。
SQL> select * from table(dbms_xplan.display());
------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 64 | 17103 | | |
| 1 | SORT AGGREGATE | | 1 | 64 | | | |
|* 2 | FILTER | | | | | | |
|* 3 | HASH JOIN SEMI | | 15167 | 947K| 17103 | | |
| 4 | TABLE ACCESS BY GLOBAL INDEX ROWID| RECORD_TEMP_A | 22142 | 648K| 10881 | ROWID | ROW L |
|* 5 | INDEX RANGE SCAN | IDX_REC_TEMP_A_SENDTIME | 39856 | | 464 | | |
|* 6 | TABLE ACCESS FULL | RECORD_TEMP_B | 682K| 22M| 5779 | 24 | 24 |
------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
省略...
Note: cpu costing is off
已选择22行。
[/PHP]
这是加了NL_SJ提示的语句及执行计划,走了NESTED LOOPS SEMI。[/COLOR]
[PHP]
SQL> explain plan for
2 select count(*)
3 from RECORD_TEMP_A t
4 where 1 = 1
5 and t.datsendtime >= sysdate - 20
6 and t.datsendtime < sysdate - 10
7 AND EXISTS (SELECT /*+ NL_SJ */ 1
8 FROM RECORD_TEMP_B partition(P_MAXVALUE) V
9 WHERE V.MSGID = T.MSGID);
已解释。
SQL> select * from table(dbms_xplan.display());
------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 64 | 77307 | | |
| 1 | SORT AGGREGATE | | 1 | 64 | | | |
|* 2 | FILTER | | | | | | |
| 3 | NESTED LOOPS SEMI | | 15167 | 947K| 77307 | | |
| 4 | TABLE ACCESS BY GLOBAL INDEX ROWID| RECORD_TEMP_A | 22142 | 648K| 10881 | ROWID | ROW L |
|* 5 | INDEX RANGE SCAN | IDX_REC_TEMP_A_SENDTIME | 39856 | | 464 | | |
|* 6 | TABLE ACCESS BY GLOBAL INDEX ROWID| RECORD_TEMP_B | 467K| 15M| 3 | 24 | 24 |
|* 7 | INDEX RANGE SCAN | IDX_REC_B_MSGID | 1 | | 2 | | |
------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
省略...
Note: cpu costing is off
已选择23行。
SQL> spool off
乙说:
问题应该在这里
TABLE ACCESS BY GLOBAL INDEX ROWID| RECORD_TEMP_A | 22142
|* 5 | INDEX RANGE SCAN | IDX_REC_TEMP_A_SENDTIME | 39856 |
这里外表评估的cardinality是错误的,跟楼主说的“满足A.idx1 between mmm and nnn条件的行一般是几百到几千行,选择性还可以”严重不符
内表结果集2万多,外表68万,CBO选择hash join无可厚非
分享到:
相关推荐
基于java的开发源码-哈希计算工具 Java-hash.zip 基于java的开发源码-哈希计算工具 Java-hash.zip 基于java的开发源码-哈希计算工具 Java-hash.zip 基于java的开发源码-哈希计算工具 Java-hash.zip 基于java的开发...
NULL 博文链接:https://juji1010.iteye.com/blog/1535638
hash join 原理和算法 1.Hash Join概述 2.Hash Join原理 3.Hash Join算法 4.Hash Join的成本
高级密码学报告------Hash算法与RSA算法分析与研究 适合高级密码学期末作业。 随着信息化和数字化社会的发展,人们对信息安全和保密的重要性认识不断提高,而在信息安全中起着举足轻重作用的密码学也就成为信息安全...
Hash join算法的一个基本思想就是根据小的row sources(称作build input,我们记较小的表为S,较大的表为B) 建立一个可以存在于hash area内存中的hash table,然后用大的row sources(称作probe input) 来探测前面所建...
分区哈希连接这是针对以下问题的作业解决方案。 给定两个1.3 GB大文件,每个文件有 1 亿个条目,找到...然后,切换到目录: $ cd partitioned-hash-join 确保脚本是可执行的: $ chmod +x partitioned_hash_join.py 该
hashcat + john-1.9.0-jumbo-1-win64, 哈希运算,破解工具
大数据-算法-基于分组密码分析设计Hash函数.pdf
Laravel开发-laravel-cake13-hash Laravel 5包使用旧版cakephp 1.3进行密码哈希
oracle hash join算法原理
最快的排序算法 最快的内容查找算法-----暴雪的Hash算法,排序算法数据结构
大数据-算法-几类密码Hash函数的设计和安全性分析.pdf
hashcat-6.1.1 hashcat-6.1.1 hashcat-6.1.1hashcat-6.1.1hashcat-6.1.1hashcat-6.1.1
前端开源库-copy-webpack-plugin-hash复制Webpack插件哈希,使用Webpack复制文件和目录
Laravel开发-laravel-md5-hash Laravel 5包使用不安全的MD5进行密码哈希
Hash join算法原理 详细讲述了oracle sql语句的连接方式 对于sql调优提高有很大帮助
内容描述:用于crypto中hash爆破的强大工具。 优势:相较于其他hash工具,具有更快的算力,使用方便简洁。 适用:适用于md5,sha256等典型hash加密方式,反推出所需的源码。
geohash官方发布以及maven发布的版本都是基于jdk1.7编译的,碰到jdk1.6的项目会报unsupported major.minor version 51.0错误。这个资源是我基于jdk1.6编译的,执行测试案例都通过了。
基于Java的实例源码-哈希计算工具 Java-hash.zip