select zzny.facility_id,
zzny.u_name,
zzny.nf year,
zzny.yd month,
nvl(hgl.lckhgl, 0)*100 lckhgl
from (select facility_id, u_name, year, month, yxts, total, bhgs, lckhgl
from ZZ_LIMS_Y_LCKHGL) hgl,
(select zz.facility_id, zz.u_name, ny.nf, ny.yd
from base_facility_tb zz,
(select distinct nf, yd from gygl_zzcbpwl_view) ny) zzny
where hgl.facility_id(+) = zzny.facility_id
and hgl.year(+) = zzny.nf
and hgl.month(+) = zzny.ydfrom 后面的两个查询第一个有1680条,第二个有112条记录,当然两个查询的数量还会增加。这两个查询的速度还算可以,但是联合之后的查询速度根本不能忍受,请问各位朋友有没有什么方法可以优化一下。谢谢了!
解决方案 »
- 我通过日志挖掘 找到了这样的数据 而且我确定 这就是我插入的数据
- oracle存储过程调用问题。
- 我们公司做业务软件,发现Oracle很难用,相比SQLServer2000
- 请教如何获取这个计费统计数据?
- 间隔一段时间后查询,速度变慢的问题
- 数据库导入问题?imp system/sa@oracledb导入到用户aaa,但用户aaa已经存在的表会跳过,我想导入并覆盖原有的表怎么做?
- 安装Oracle817后,windows2000的FTP不能用了,如何解决?
- 如何union一条记录?
- Oracle数据库的读取如何保证实时性
- 关于数据库事务特性和它的隔离级别的困惑?
- 在查询日期字段显示短日期。
- Oracle临时表使用问题
from base_facility_tb zz,
(select distinct nf, yd from gygl_zzcbpwl_view) ny
你这个语句做笛卡尔积了,???
看执行计划不会卡死的,你可以在pl/sql developer中选中你那条SQL,然后F5如果要建索引的话,where后面的条件所涉及的字段都可以考虑,但索引效率的高低
要由实际选择性情况来决定。
再次建议,如果gygl_zzcbpwl_view是视图,应该考虑优化它先。特别是避免类似万能视图一样的东西。
SELECT STATEMENT, GOAL = CHOOSE 1731 5908 992544
HASH JOIN OUTER 1731 5908 992544
VIEW PTQM 51 409 51125
MERGE JOIN CARTESIAN 51 409 51125
VIEW PTQM 49 1 10
SORT UNIQUE 49 1 100
FILTER
HASH JOIN OUTER
FILTER
HASH JOIN OUTER
HASH JOIN 21 1 58
VIEW PTQM GYGL_NZZCBPWL_VIEW 9 3 57
SORT GROUP BY 9 3 36
TABLE ACCESS FULL PTQM GYGL_CSCBSTJ_TB 3 2280 27360
VIEW PTQM GYGL_BZZCBPWL_VIEW 11 45 1755
SORT GROUP BY 11 45 765
TABLE ACCESS FULL PTQM GYGL_CSCBSTJ_TB 3 2280 38760
VIEW PTQM GYGL_RZZCBPWL_VIEW 9 3 60
SORT GROUP BY 9 3 36
TABLE ACCESS FULL PTQM GYGL_CSCBSTJ_TB 3 2280 27360
VIEW PTQM GYGL_YZZCBPWL_VIEW 16 3 66
SORT GROUP BY 16 3 1581
HASH JOIN 6 164 86428
TABLE ACCESS FULL PTQM GYGL_CSFW_TB 2 20 10300
TABLE ACCESS FULL PTQM GYGL_CSCBSTJ_TB 3 2280 27360
BUFFER SORT 51 409 47035
TABLE ACCESS FULL PTQM BASE_FACILITY_TB 2 409 47035
VIEW PTQM 1656 144441 6210963
NESTED LOOPS OUTER 1656 144441 9533106
VIEW PTQM 20 1636 49080
MERGE JOIN CARTESIAN 20 1636 49080
MERGE JOIN CARTESIAN 12 4 68
VIEW PTQM 4 2 26
COUNT STOPKEY
VIEW SYS USER_OBJECTS 4 2
UNION-ALL
FILTER
TABLE ACCESS BY INDEX ROWID SYS OBJ$ 3 1 122
INDEX RANGE SCAN SYS I_OBJ2 2 1
TABLE ACCESS BY INDEX ROWID SYS IND$ 2 1 26
INDEX UNIQUE SCAN SYS I_IND1 1 1
INDEX RANGE SCAN SYS I_LINK1 2 1 13
BUFFER SORT 12 2 8
VIEW PTQM 4 2 8
COUNT STOPKEY
VIEW SYS USER_OBJECTS 4 2
UNION-ALL
FILTER
TABLE ACCESS BY INDEX ROWID SYS OBJ$ 3 1 122
INDEX RANGE SCAN SYS I_OBJ2 2 1
TABLE ACCESS BY INDEX ROWID SYS IND$ 2 1 26
INDEX UNIQUE SCAN SYS I_IND1 1 1
INDEX RANGE SCAN SYS I_LINK1 2 1 13
BUFFER SORT 16 409 5317
TABLE ACCESS FULL PTQM BASE_FACILITY_TB 2 409 5317
VIEW PUSHED PREDICATE PTQM ZZ_LIMS_Y_LCKHGL1 1 88 3168
HASH JOIN 4281 3611022 996642072
VIEW PTQM 2574 355145 3551450
SORT UNIQUE 2574 355145 2486015
TABLE ACCESS FULL PTQM TB_ITEM_DATA_LIST_VW 420 355145 2486015
HASH JOIN 822 101677 27046082
HASH JOIN 4 4 920
TABLE ACCESS BY INDEX ROWID PTQM BASE_FACILITY_TB 1 4 460
INDEX RANGE SCAN PTQM PK_BASE_FACILITY_TB 1 2
TABLE ACCESS FULL PTQM BASE_FACILITY_LIMS_TB 2 327 37605
VIEW PTQM 817 24860 894960
SORT GROUP BY 817 24860 3530120
HASH JOIN 435 24860 3530120
VIEW SYS VW_NSO_1 4 7 581
SORT UNIQUE 4 7 672
TABLE ACCESS FULL PTQM LIMS_XM_SFKH 2 7 672
TABLE ACCESS FULL PTQM TB_ITEM_DATA_LIST_VW 420 355145 20953555
谢谢!gygl_zzcbpwl_view是个视图,但是这个查询(select zz.facility_id, zz.u_name, ny.nf, ny.yd
from base_facility_tb zz,
(select distinct nf, yd from gygl_zzcbpwl_view) ny) zzny
并没有占用多少时间,就是两个查询之后的连接有问题,但是不知道这样还有可能优化的余地吗。
可能需要优化一下
肯定是有问题的(除非对这个表查询没有条件)
是不是gygl_zzcbpwl_view视图从这个表取数据,
gygl_zzcbpwl_view的定义?
create or replace view gygl_zzcbpwl_view as
select
from gygl_bzzcbpwl_view b,
gygl_rzzcbpwl_view r,
gygl_yzzcbpwl_view y,
gygl_nzzcbpwl_view n
where b.facility_id = r.facility_id
and b.facility_id = y.facility_id
and b.facility_id = n.facility_id
and b.rq = r.RQ(+)
and b.yf = y.yf(+)
and b.nf = n.nf
取数用到的几个视图gygl_bzzcbpwl_view等,是从另一个表取的,其数据量也是很大。
(select distinct nf, yd from gygl_zzcbpwl_view) ny)
建成了物化视图zzny。 但是查询速度提高的幅度并不理想,从查询计划上看查询仍然走了物化视图zzny的基础表。为什么不是直接从物化视图zzny中提取数据呢?物化视图不是相当于一张真实的表吗?
物化视图是基于本地副本来查询的
(select distinct nf, yd from gygl_zzcbpwl_view) ny)
是造成速度慢的主要原因,于是我将这个查询建成了物化视图。但是速度上还是挺慢,当然也快了很多。但是如果我将这个查询的数据放进表里,速度就很快了。我不解的是,物化视图和表不是一样的吗?怎么会慢这么多呢?
create materialized view ZZNY
refresh force on demand
as
select zz.facility_id, zz.u_name, ny.nf, ny.yd
from base_facility_tb zz,
(select distinct nf, yd from gygl_zzcbpwl_view) ny
还有我刚发现物化视图老是失效,基础表并没有动过啊找不到原因这也是第一次使用物化视图汗。