oracle 不能走索引问题

liubin041102 2012-03-13 06:25:03
SQL 语句:
SELECT t.CSTM_NO,t.acc
CM.CUSTMER_MANAGER_ID
FROM MPM_PCUST_MNG_INFO CM,
MPM_PACC_INFO t
WHERE CM.CUSTMER_MANAGER_ID = '330118065'
AND CM.CONFORM_INDPARTY_ID = t.CSTM_NO;
索引 :
MPM_PCUST_MNG_INFO表:
alter table MPM_PCUST_MNG_INFO add constraint PCUST_MNG_INFO primary key (CONFORM_INDPARTY_ID, CUSTMER_MANAGER_ID)
MPM_PACC_INFO 表:
create index PACC_CSTM_NO_IDX on MPM_PACC_INFO (CSTM_NO, ACC_TYPE, OPEN_INST) 。
得到的执行计划如下:
SELECT STATEMENT, GOAL = ALL_ROWS 411842 9 468
HASH JOIN 411842 9 468
INDEX FULL SCAN MPM PCUST_MNG_INFO 1 4 68
PARTITION RANGE ALL 411243 66416252 2324568820
TABLE ACCESS FULL MPM MPM_PACC_INFO 411243 66416252 2324568820

MPM_PCUST_MNG_INFO表数据量100多条,关联CM.CUSTMER_MANAGER_ID = '330118065'条件后只有2条记录,MPM_PACC_INFO表有6600多万记录,而且经过分区的。
还请CSDN各位大侠解答,为什么MPM_PACC_INFO表没有走PACC_CSTM_NO_IDX这个索引,在另外的测试环境上,MPM_PACC_INFO记录只有200多万的时候是能够走索引的。
...全文
140 9 打赏 收藏 转发到动态 举报
写回复
用AI写文章
9 条回复
切换为时间正序
请发表友善的回复…
发表回复
争取今天 2012-03-14
  • 打赏
  • 举报
回复
先看看统计信息能不能反应表中数据的实际情况。一般情况下10g以上的版本会进行内部查询变换,尝试用不同的表作驱动表,然后比对结果。选择最优算法。分析表然后让优化器重新解释一下。
=======================
如果分析后依然不能获得很好效果,你可以重写一下语句
SELECT t.CSTM_NO,t.acc
'330118065' CUSTMER_MANAGER_ID
FROM MPM_PACC_INFO t
where t.cstm_no in (select cm.CONFORM_INDPARTY_ID from MPM_PCUST_MNG_INFO CM
where cm.CUSTMER_MANAGER_ID='330118065')

====================================
或者加些提示
======================
当然,也可能是你的PACC_CSTM_NO_IDX 情况太差,这个索引即使用上也是
简易人 2012-03-13
  • 打赏
  • 举报
回复
支持2楼的同类!
renfengjun 2012-03-13
  • 打赏
  • 举报
回复
首先看看优化器是否是cbo。
使用普通的查询和使用hint强制走索引看看两个执行计划。
如果看到普通查询消耗的资源少那么看看表的碎片是不是太多了,再看看索引的层级。
如果看到普通查询消耗的资源多,那么看一下表是否太长时间没有收集过统计信息。
liubin041102 2012-03-13
  • 打赏
  • 举报
回复
[Quote=引用 3 楼 youqi1984 的回复:]

为什么MPM_PACC_INFO表没有走PACC_CSTM_NO_IDX这个索引
--------------------------------------
where 条件没有PACC_CSTM_NO_IDX列。怎么走、
[/Quote]
where 条件中的 t.CSTM_NO 就是PACC_CSTM_NO_IDX 的第一列啊
liubin041102 2012-03-13
  • 打赏
  • 举报
回复
[Quote=引用 1 楼 luiseradl 的回复:]

数据库本身设置的问题,当数据量比较小的时候,走索引的开销更大。
而当数据量特别大的时候,走索引是最优的。

这与数据库本身设置的优化策略有有关。
[/Quote]
MPM_PACC_INFO 这个表数据量有6600多万,所以没走索引才耗时长。所以我想问问是不是数据库本身的设置,导致索引失效
liubin041102 2012-03-13
  • 打赏
  • 举报
回复
[Quote=引用 2 楼 hebeishimeng 的回复:]

引用 1 楼 luiseradl 的回复:

数据库本身设置的问题,当数据量比较小的时候,走索引的开销更大。
而当数据量特别大的时候,走索引是最优的。

这与数据库本身设置的优化策略有有关。

当查询结果数据量大于30%时,不建议使用索引。
[/Quote]

查询结果小于10条,而原表MPM_PACC_INFO有6600万数据。
youqi1984 2012-03-13
  • 打赏
  • 举报
回复
为什么MPM_PACC_INFO表没有走PACC_CSTM_NO_IDX这个索引
--------------------------------------
where 条件没有PACC_CSTM_NO_IDX列。怎么走、
raymonshi 2012-03-13
  • 打赏
  • 举报
回复
[Quote=引用 1 楼 luiseradl 的回复:]

数据库本身设置的问题,当数据量比较小的时候,走索引的开销更大。
而当数据量特别大的时候,走索引是最优的。

这与数据库本身设置的优化策略有有关。
[/Quote]
当查询结果数据量大于30%时,不建议使用索引。
我心飞翔 2012-03-13
  • 打赏
  • 举报
回复
数据库本身设置的问题,当数据量比较小的时候,走索引的开销更大。
而当数据量特别大的时候,走索引是最优的。

这与数据库本身设置的优化策略有有关。

17,078

社区成员

发帖
与我相关
我的任务
社区描述
Oracle开发相关技术讨论
社区管理员
  • 开发
  • Lucifer三思而后行
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧