为什么加上索引速度奇慢无比？

jimmylee

thanks rejoice999 for your help.
但是速度还是非常慢呀，如何解决呢？

biti_rainy

order by 是否利用了索引
你的整个查询是否合理的利用了索引
这是最关键的两个因素

可能的话
trace 一把，tkprof 看看慢在哪里

lwxian

最初由 jimmylee 发布
需要说明的是目前的记录的moni_area,moni_typeid,moni_flag都是相同的，就是说目前的99万条记录加不加where语句查询的记录集都是一样的（但将来可能不一定）
[/B]

这不相当于全表扫描？当然慢了，建议建立如下索引：
create index index2 on cstmonilog(moni_area,moni_typeid,moni_flag,moni_time)
)


因为你看一下你的统计：
1 sorts (disk)
前面一个是没有sorts (disk)


SQL改为：
select  rowid  rID, MONI_TIME,MONI_TYPE,MONI_APERRCODE,MONI_CONSTANT,SubStr(MONI_USERINFO,1,50) MONI_USERINFO

from cstmonilog
where rowid IN
(select rid from  (select rownum rno,rowid /*+ INDEX(cstmonilog index2 ) */ rid from cstmonilog where MONI_AREA = :MoniAreaNo and MONI_TYPEID = :MoniTypeID and MONI_FLAG = '1' and rownum <:MoniNoLast
order by MONI_TIME) where rNo >=:MoniNoFirst )
order by MONI_TIME;

jimmylee

99万条记录，order  by 确实利用了索引，但如果用row_number没有用索引，why?

DeepBlue

影响了优化器的判断,优化器根据索引的存在选择了一条他认为好,实际上更坏的执行路径

yafeng

-------------------------------------------------------------------
需要说明的是目前的记录的moni_area,moni_typeid,moni_flag都是相同的，就是说目前的99万条记录加不加where语句查询的记录集都是一样的（但将来可能不一定）
-------------------------------------------------------------------
这样子还有必要建索引？即便将来有不同，索引的区分度也太低。

jimmylee

最初由 lwxian 发布
[B]


这不相当于全表扫描？当然慢了，建议建立如下索引：
create index index2 on cstmonilog(moni_area,moni_typeid,moni_flag,moni_time)
)


因为你看一下你的统计：
1 sorts (disk)
前面一个是没有sorts (disk) [/B]

加上这样的索引，执行计划显示使用index2而不用index1，但速度比index1慢多了，一个是33秒，一个是167秒。看来目前只是moni_time域使用了索引。

jimmylee

最初由 DeepBlue 发布
[B]影响了优化器的判断,优化器根据索引的存在选择了一条他认为好,实际上更坏的执行路径 [/B]

如何解决？

lwxian

最初由 jimmylee 发布
[B]

加上这样的索引，执行计划显示使用index2而不用index1，但速度比index1慢多了，一个是33秒，一个是167秒。看来目前只是moni_time域使用了索引。 [/B]

你有用我的SQL测试吗？

jimmylee

最初由 lwxian 发布
[B]


你有用我的SQL测试吗？ [/B]

是的，我试了一下，速度确实比以前快了不少，以前是2分多，你的做法是1分多，基本提高了一倍。但速度还是有些慢。