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

最初由 lwxian 发布
[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;
[/B]

这个语句出来的结果对吗？ 要是对的，我想是你运气不错

drop index index1;
drop index index2;


create index index1 on cstmonilog(moni_time) nologing;

set timing on
set autot traceonly

select * from (
select rownum rno, a.*
from
(select MONI_TIME,MONI_TYPE,MONI_APERRCODE,MONI_CONSTANT,SubStr(MONI_USERINFO,1,50) MONI_USERINFO
from cstmonilog
where MONI_AREA = :MoniAreaNo and MONI_TYPEID = :MoniTypeID and MONI_FLAG = '1'
order by MONI_TIME)  a where rownum <= 20
) where rno >= 5
/

保证你以秒级速度运行。

正如楼上某哥说的，你index2不建也罢。另外，从顶楼的贴子看来，执行计划与所建INDEX不一至。第一个应该是用inex1,第二应该用INDEX2。兄弟提个建议，各位如果有条件，请尽量原模原样COPY你在SQLPLUS 试验的情况。至于你为什么会加了INDEX而慢，你看看你用的是什么optimizer mode 就可以明白了。从你的语句看，我猜你的DB是8。1。5以上版本，建议采用COST OPTIMIZER。

biti_rainy

反正我以前在50万记录中的测试
翻任意一页，都可以控制在3秒以内

哥们，你是怎么做的？ my method is limited. I can ensure the sql I supplied can return the result very quicky if the MoniNoLast I specified is less than 5000 or a little more, but it will become slower and slower when the MoniNoLast get closed to the total number of rows in the table.

jimmylee

最初由 biti_rainy 发布
[B]反正我以前在50万记录中的测试
翻任意一页，都可以控制在3秒以内 [/B]

能否将你的做法共享出来，大家学学。

biti_rainy

忘了交代一个前提
那就是：

表的行记录不大，反正肯定不超过100字节
所以记录和索引全部都装在内存里面啦

jimmylee

我的表肯定不行，每条记录的长度理论的大小将近8K.

jimmylee

我测试的结果lwxian的语句速度是最快的。能否给解释一下为什么？

biti_rainy

select rownum rno,rowid /*+ INDEX(cstmonilog index2 ) */ rid from

还要注意在这一层的where条件中的所有字段都包含在索引中！

这是什么意思，表示所有字段和rowid都从索引里面来，而不用进行表扫描
通过索引确定了你要选取的记录的位置
然后再通过rowid去扫描表

因索引中只包含部分字段，内层使用的内存就少了

因为进行表扫描的时候不管你选取所有字段还是一个字段，都是把所有列读进内存的！

biti_rainy

那就是你的瓶颈在内存和io上

这样的话，你可以考虑把你的要排序的和内层的wher中字段单独放在一个表中
通过这些小表确定记录集
然后再通过这个结果集去大表中查询

本来想用 IOT的，一样可缓解楼上的所说的问题，但考虑到它限制了其他索引的存在，就算了