一条SQL语句的优化过程?

[复制链接]
查看11 | 回复9 | 2011-1-4 10:35:48 | 显示全部楼层 |阅读模式
1.没有索引时:
SELECT ROWID, job_num1, z_part_num, part_num, part_num1, des_num, job_num,
des_size, des_p, name, piece, mat, unit_w, type_code, bj_code, des_work,
ymd, nanum
FROM list_temp
WHERE nanum = 1
ORDER BY REPLACE(job_num, 'M');
执行计划为:
SELECT STATEMENT, GOAL = CHOOSE
Cost=738
Cardinality=11254
Bytes=1192924
SORT ORDER BY
Cost=738
Cardinality=11254
Bytes=1192924
TABLE ACCESS FULL
Object owner=DSJ
Object name=LIST_TEMP
Cost=673
Cardinality=11254
Bytes=1192924
2.建立索引,优化SQL
create index list_temp_ls2 on list_temp(nanum,REPLACE(job_num, 'M'))
tablespace mrp_5_idx;
建完索引后,再执行SQL,执行计划变为:
SELECT STATEMENT, GOAL = CHOOSE
Cost=7
Cardinality=11254
Bytes=1192924
TABLE ACCESS BY INDEX ROWID
Object owner=DSJ
Object name=LIST_TEMP
Cost=7
Cardinality=11254
Bytes=1192924
INDEX RANGE SCAN
Object owner=DSJ
Object name=LIST_TEMP_LS2
Cost=2
Cardinality=11254

成本为7,已经优化了。
3、重新分析表和索引后,再执行SQL语句,奇怪,执行计划又回原来的:
analyze table list_temp compute statistics;
analyze index list_temp_ls compute statistics;
执行SQL语句,执行计划又变回去了:
SELECT STATEMENT, GOAL = CHOOSE
Cost=738
Cardinality=11254
Bytes=1192924
SORT ORDER BY
Cost=738
Cardinality=11254
Bytes=1192924
TABLE ACCESS FULL
Object owner=DSJ
Object name=LIST_TEMP
Cost=673
Cardinality=11254
Bytes=1192924


成本为738,又不优化了。
问题:我见索引后,成本从738到3优化了SQL语句,可是为什么我
马上执行分析表和索引后,SQL语句又不优化了那?
????????请高手指点
回复

使用道具 举报

千问 | 2011-1-4 10:35:48 | 显示全部楼层
第二步走的索引并不是你建的那条
回复

使用道具 举报

千问 | 2011-1-4 10:35:48 | 显示全部楼层
optimizer_index_cost_adj为多少?
回复

使用道具 举报

千问 | 2011-1-4 10:35:48 | 显示全部楼层
SELECT STATEMENT, GOAL = CHOOSE
Cost=7
Cardinality=11254
Bytes=1192924
TABLE ACCESS BY INDEX ROWID
Object owner=DSJ
Object name=LIST_TEMP
Cost=7
Cardinality=11254
Bytes=1192924
INDEX RANGE SCAN
Object owner=DSJ
Object name=LIST_TEMP_LS2
Cost=2
Cardinality=11254
回复

使用道具 举报

千问 | 2011-1-4 10:35:48 | 显示全部楼层
optimizer_index_cost_adj
integer 100
回复

使用道具 举报

千问 | 2011-1-4 10:35:48 | 显示全部楼层
这种情况很常见,因为分析后,统计信息变化了,Oracle认为走FTS的代价更低,如果你想知道更详细的信息,那要作一个10053的trace.
Oracle也是个软件,选择执行计划偶尔也会错误,这种时候就需要人工干预,如果你认为走索引更好,完全可以通过加hint的方式来固定执行计划。
回复

使用道具 举报

千问 | 2011-1-4 10:35:48 | 显示全部楼层
最初由 freezr 发布
[B]这种情况很常见,因为分析后,统计信息变化了,Oracle认为走FTS的代价更低,如果你想知道更详细的信息,那要作一个10053的trace.
Oracle也是个软件,选择执行计划偶尔也会错误,这种时候就需要人工干预,如果你认为走索引更好,完全可以通过加hint的方式来固定执行计划。 [/B]

学习!
回复

使用道具 举报

千问 | 2011-1-4 10:35:48 | 显示全部楼层
5楼说的有道理。。。
回复

使用道具 举报

千问 | 2011-1-4 10:35:48 | 显示全部楼层
应该是固化的,但是后来又不走索引了,只有第二步走到了LIST_TEMP_LS2这个索引 做个trace看看吧
回复

使用道具 举报

千问 | 2011-1-4 10:35:48 | 显示全部楼层
是否分析了字段?很多时候与histogram和是否使用了绑定变量有关
回复

使用道具 举报

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

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行