请帮忙看看为何不使用index

mustanglala · 发表于 2008-4-9 13:20

select * from v$version

Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
PL/SQL Release 9.2.0.8.0 - Production
"CORE 9.2.0.8.0 Production"
TNS for 32-bit Windows: Version 9.2.0.8.0 - Production
NLSRTL Version 9.2.0.8.0 - Production

棉花糖ONE · 发表于 2008-4-9 13:21

CLUSTERING_FACTOR 4203827

mihawk · 发表于 2008-4-9 13:35

TABLE ACCESS FULL       SFISM4       H_SN_DETAIL_T       15204       1071937       211171589
cost:15204

TABLE ACCESS BY INDEX ROWID       SFISM4       H_SN_DETAIL_T       805099       1071937       211171589
  INDEX RANGE SCAN       SFISM4       H117_TIME       9366       1071937
cost:805099

就当前给出的执行计划来看, 全表扫描的成本是15204, 而索引范围扫描的总成本是805099, cbo选择前者是正确的.
分析一下table(r_sn_detail_t), index(h117_time), column(in_station_time)的统计信息吧.

mustanglala · 发表于 2008-4-9 13:45

TKs up 2

那就是说CLUSTERING_FACTOR 更接近 Rows_num 意味着按该索引存取的效率太低， cbo 就自动choose table access full ？

那表的数据是按该表上创建的第一个索引来组织存储的吗？
复合索引的情况下存取效率会好么？
又或者该单列索引重建后存取的效率就会高呢？

现在是Job time我怕收集统计信息会影响生产，实际上我自己并没有做过统计

棉花糖ONE · 发表于 2008-4-9 14:11

如果你觉得强制走索引是比全表慢,说明oracle走的是对的,这情况你收集统计信息oracle应该还是选全表
如果你觉得强制走索引是比全表快,收集统计信息就有好处,收集后oracle可能就走索引了

不过,那也太长时间没收集统计信息了

mihawk · 发表于 2008-4-9 14:18

原帖由 mustanglala 于 2008-4-9 13:45 发表
TKs up 2

那就是说CLUSTERING_FACTOR 更接近 Rows_num 意味着按该索引存取的效率太低， cbo 就自动choose table access full ？

那表的数据是按该表上创建的第一个索引来组织存储的吗？
复合索引的情况下存取效率会好么？
又或者该单列索引重建后存取的效率就会高呢？

现在是Job time我怕收集统计信息会影响生产，实际上我自己并没有做过统计

1.
Q:那表的数据是按该表上创建的第一个索引来组织存储的吗？
A:不是.这是一个严重的误区, 简单的说, 表中的数据是无序的. IOT(索引组织表)除外.

2.
Q:复合索引的情况下存取效率会好么？
A:复合索引跟这个SQL好像关系不大. 这么说吧, 完全索引存取效率会很好.
所谓完全索引就是指, 一个索引包含了一个SQL中所访问的所有字段, 且以SQL中的谓词字段为索引的首字段.
这种索引存在的话, 对应的SQL只需要做索引范围扫描就可以得到结果, 而不需要再去访问表了, 对应SQL的性能可以提高很多.

但是这种索引有局限性, 首先它只针对特定SQL有特效, 但是它的存在很可能导致其他不该使用该索引的SQL走错索引, 而导致数据库崩溃.所以慎用.

3.
Q:又或者该单列索引重建后存取的效率就会高呢？
A:索引重建对clustering_factor没有任何影响.
这也是一个严重的误区, 因为clustering_factor反应的是表中的数据相对索引排列的混乱程度.
要改变这个参数只有一个办法:

create table t_1 as select * from t order by xxx,xxx;

就是按索引的顺序重新组织表中的数据, 不过相信没有人会这么去做的.
另一个办法就是用IOT(索引组织表), 原因参见第一个问题的回答.