优化场景:以下语句执行用时84s,
select count(*)
from t_zz_support_object t1, T_DC_CI_RS_TOP t3
where t1.status = 1
and t1.ci_rs_id = t3.ci_rs_id
and t1.org_id in (
select org_id from t_dc_org_entity_info start with org_id = 3213 connect by prior org_id = parent_org_id
)
优化过程:
@Tony(943004851) 10:40:13
你看看执行计划 返回的基数 是不是和查询的一致
启用10053 事件 跟踪一下
启用10053 事件 跟踪一下
index full scan 和扫描全表几乎差不多
1万以上的逻辑读和执行计划里的cost=0显然不符,执行计划说KEY_T_DC_CIRS的全扫描cost为0,和你说的表的数据量很大不符。就是统计信息的问题,你的表数据最近发生大变动了,变动后没有刷新统计信息
手动刷新统计信息语句速度上去了:
为什么select count(1) from 84秒 select * from 0.015 秒
Tony(943004851) 10:56:40
第一个查询完 要进行一次count操作 这是几乎块操作 要所有的块都查询完 在进行count
第二个是非块操作 即行读取 一行一行的读取
分析@awrpt
前两个语句共用了72.27%的逻辑读,KEY_T_DC_CIRS逻辑读 54%,
Tony(943004851) 10:56:40
第一个查询完 要进行一次count操作 这是几乎块操作 要所有的块都查询完 在进行count
第二个是非块操作 即行读取 一行一行的读取
分析@awrpt
1万以上的逻辑读和执行计划里的cost=0显然不符,执行计划说KEY_T_DC_CIRS的全扫描cost为0,和你说的表的数据量很大不符。就是统计信息的问题,你的表数据最近发生大变动了,变动后没有刷新统计信息
手动刷新统计信息语句速度上去了:
begin
dbms_stats.gather_table_stats(ownname => 'zhsq', tabname => 'T_DC_CI_RS_TOP',
estimate_percent => 0.5, method_opt => 'for all columns size skewonly',cascade => TRUE);
end;
执行后的语句执行计划:
dbms_stats.gather_table_stats(ownname => 'zhsq', tabname => 'T_DC_CI_RS_TOP',
estimate_percent => 0.5, method_opt => 'for all columns size skewonly',cascade => TRUE);
end;
执行后的语句执行计划:
怎么看 执行计划是否接近完美
Tony(943004851) 12:30:05
最直观的方法就是 看你执行计划返回的行数或者cardinality(基数) 和你数据表或其他对象 是否一致
还要分析 表、索引和相关列的统计信息 是以统筹的概念和信息
Tony(943004851) 12:30:05
最直观的方法就是 看你执行计划返回的行数或者cardinality(基数) 和你数据表或其他对象 是否一致
还要分析 表、索引和相关列的统计信息 是以统筹的概念和信息