这个表里面只有3条记录,建了索引后,查询性能为何改善这么多?

[复制链接]
查看11 | 回复9 | 2008-6-30 01:01:54 | 显示全部楼层 |阅读模式
SQL> select bd_accsubj.pk_accsubj,
2 bd_accsubj.subjcode,
3 bd_accsubj.subjname,
4 bd_accsubj.endflag
5from bd_accsubj
6 where bd_accsubj.pk_glorgbook = '0001A8100000000012H0'
7 and sealflag is null
8 and exists
9 (select subj1.Pk_accsubj
10
from bd_accsubj subj1, gl_verifyObj
11
where gl_verifyObj.Pk_accsubj = subj1.Pk_accsubj
12
and (gl_verifyObj.pk_glorgbook = '0001A810000000001NHP' and
13
bd_accsubj.subjcode like subj1.subjcode || '%' and
14
gl_verifyObj.userFlag = 'Y' and bd_accsubj.endflag = 'Y'))
15
SQL> /
no rows selected

Execution Plan
----------------------------------------------------------
Plan hash value: 720873777
-------------------------------------------------------------------------------------------------
| Id| Operation
| Name | Rows| Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT
|
| 1 |66 |1983 (1)| 00:00:24 |
|*1 |FILTER
|
| | |
|
|
|*2 | TABLE ACCESS BY INDEX ROWID| BD_ACCSUBJ | 430 | 28380 |44 (0)| 00:00:01 |
|*3 |INDEX RANGE SCAN
| I_BD_ACCSUBJ_3 | 430 | | 2 (0)| 00:00:01 |
|*4 | FILTER
|
| | |
|
|
| 5 |NESTED LOOPS
|
| 1 |83 | 9 (0)| 00:00:01 |
|*6 | TABLE ACCESS FULL
| GL_VERIFYOBJ | 1 |53 | 8 (0)| 00:00:01 |
|*7 | TABLE ACCESS BY INDEX ROWID| BD_ACCSUBJ | 1 |30 | 1 (0)| 00:00:01 |
|*8 |INDEX UNIQUE SCAN | PK_BD_ACCSUBJ| 1 | | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter( EXISTS (SELECT /*+ */ 0 FROM "GL_VERIFYOBJ" "GL_VERIFYOBJ","BD_ACCSUBJ"

"SUBJ1" WHERE :B1='Y' AND "GL_VERIFYOBJ"."PK_ACCSUBJ"="SUBJ1"."PK_ACCSUBJ" AND :B2 LIKE

"SUBJ1"."SUBJCODE"||'%' AND "GL_VERIFYOBJ"."USERFLAG"='Y' AND

"GL_VERIFYOBJ"."PK_GLORGBOOK"='0001A810000000001NHP'))
2 - filter("SEALFLAG" IS NULL)
3 - access("BD_ACCSUBJ"."PK_GLORGBOOK"='0001A8100000000012H0')
4 - filter(:B1='Y')
6 - filter("GL_VERIFYOBJ"."USERFLAG"='Y' AND

"GL_VERIFYOBJ"."PK_GLORGBOOK"='0001A810000000001NHP')
7 - filter(:B1 LIKE "SUBJ1"."SUBJCODE"||'%')
8 - access("GL_VERIFYOBJ"."PK_ACCSUBJ"="SUBJ1"."PK_ACCSUBJ")

Statistics
----------------------------------------------------------

1recursive calls

0db block gets
10918consistent gets
142physical reads

0redo size
406bytes sent via SQL*Net to client
339bytes received via SQL*Net from client

1SQL*Net roundtrips to/from client

0sorts (memory)

0sorts (disk)

0rows processed
SQL>
SQL>
SQL> /
no rows selected



select * fromgl_verifyObj---这个表里面只有3条记录
create index IDX_GL_VERIFYOBJ8on gl_verifyObj(pk_glorgbook,userFlag) online compute statisticstablespace nnc_index02 ;


建了个索引后,为何逻辑读下降那么厉害?
见过索引后的执行计划如下:






Execution Plan
----------------------------------------------------------
Plan hash value: 3972076677
----------------------------------------------------------------------------------------------------
| Id| Operation
| Name
| Rows| Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT
|
| 1 |66 | 474 (0)| 00:00:06 |
|*1 |FILTER
|
| | |
|
|
|*2 | TABLE ACCESS BY INDEX ROWID| BD_ACCSUBJ| 430 | 28380 |44 (0)| 00:00:01 |
|*3 |INDEX RANGE SCAN
| I_BD_ACCSUBJ_3| 430 | | 2 (0)| 00:00:01 |
|*4 | FILTER
|
| | |
|
|
| 5 |NESTED LOOPS
|
| 1 |83 | 2 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| GL_VERIFYOBJ| 1 |53 | 1 (0)| 00:00:01 |
|*7 |INDEX RANGE SCAN
| IDX_GL_VERIFYOBJ8 | 1 | | 1 (0)| 00:00:01 |
|*8 | TABLE ACCESS BY INDEX ROWID| BD_ACCSUBJ| 1 |30 | 1 (0)| 00:00:01 |
|*9 |INDEX UNIQUE SCAN | PK_BD_ACCSUBJ | 1 | | 1 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter( EXISTS (SELECT /*+ */ 0 FROM "GL_VERIFYOBJ" "GL_VERIFYOBJ","BD_ACCSUBJ"

"SUBJ1" WHERE :B1='Y' AND "GL_VERIFYOBJ"."PK_ACCSUBJ"="SUBJ1"."PK_ACCSUBJ" AND :B2 LIKE

"SUBJ1"."SUBJCODE"||'%' AND "GL_VERIFYOBJ"."USERFLAG"='Y' AND

"GL_VERIFYOBJ"."PK_GLORGBOOK"='0001A810000000001NHP'))
2 - filter("SEALFLAG" IS NULL)
3 - access("BD_ACCSUBJ"."PK_GLORGBOOK"='0001A8100000000012H0')
4 - filter(:B1='Y')
7 - access("GL_VERIFYOBJ"."PK_GLORGBOOK"='0001A810000000001NHP' AND

"GL_VERIFYOBJ"."USERFLAG"='Y')
8 - filter(:B1 LIKE "SUBJ1"."SUBJCODE"||'%')
9 - access("GL_VERIFYOBJ"."PK_ACCSUBJ"="SUBJ1"."PK_ACCSUBJ")

Statistics
----------------------------------------------------------

1recursive calls

0db block gets
622consistent gets

0physical reads

0redo size
406bytes sent via SQL*Net to client
339bytes received via SQL*Net from client

1SQL*Net roundtrips to/from client

0sorts (memory)

0sorts (disk)

0rows processed
回复

使用道具 举报

千问 | 2008-6-30 01:01:54 | 显示全部楼层
Statistics
----------------------------------------------------------

1recursive calls

0db block gets
10918consistent gets
142physical reads----这里

0redo size
406bytes sent via SQL*Net to client
339bytes received via SQL*Net from client

1SQL*Net roundtrips to/from client

0sorts (memory)

0sorts (disk)

0rows processed

==============================================================================
Statistics
----------------------------------------------------------

1recursive calls

0db block gets
622consistent gets

0physical reads

0redo size
406bytes sent via SQL*Net to client
339bytes received via SQL*Net from client

1SQL*Net roundtrips to/from client

0sorts (memory)

0sorts (disk)

0rows processed
应该是你第1次执行的时候,很多 physical reads ,所以 consistent gets 也就比较高,第2次从buffer 里取数据所以快很多。
你可以把index drop 掉 然后 重复执行下你的语句 看性能对比!
回复

使用道具 举报

千问 | 2008-6-30 01:01:54 | 显示全部楼层
|*6 | TABLE ACCESS FULL
| GL_VERIFYOBJ | 1 |53 | 8 (0)| 00:00:01 |
看看这个表占用的block数
回复

使用道具 举报

千问 | 2008-6-30 01:01:54 | 显示全部楼层
重新执行,物理读会少,逻辑读还是一样
回复

使用道具 举报

千问 | 2008-6-30 01:01:54 | 显示全部楼层
那是不是有可能 这表数据被delete 过 ,高水位线 没降下来!
[ 本帖最后由 lorikyo 于 2011-1-12 11:28 编辑 ]
回复

使用道具 举报

千问 | 2008-6-30 01:01:54 | 显示全部楼层
我记得 有recursive calls,physical reads 时候
consistent gets 会增加的?
回复

使用道具 举报

千问 | 2008-6-30 01:01:54 | 显示全部楼层
full table scan的概念。即使1条记录也没有,也需要扫描HWM以下的所有块
回复

使用道具 举报

千问 | 2008-6-30 01:01:54 | 显示全部楼层
原帖由 棉花糖ONE 于 2011-1-12 11:05 发表
|*6 | TABLE ACCESS FULL
| GL_VERIFYOBJ | 1 |53 | 8 (0)| 00:00:01 |
看看这个表占用的block数


不多
Total Blocks............................32
Total Bytes.............................262144
Unused Blocks...........................0
Unused Bytes............................0
Last Used Ext FileId....................11
Last Used Ext BlockId...................1174793
Last Used Block.........................32
回复

使用道具 举报

千问 | 2008-6-30 01:01:54 | 显示全部楼层
对于3行来说,占用32个block也不少了
create tableas select * from t ;
然后用新建的这个3行的表代替原来的表,再测试
[ 本帖最后由 棉花糖ONE 于 2011-1-12 12:05 编辑 ]
回复

使用道具 举报

千问 | 2008-6-30 01:01:54 | 显示全部楼层
10918consistent gets
622consistent gets
延迟块清除?
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行