其实我刚才已经发帖求助了,就是那个十万火急的帖子,但是没有找到答案,另外我又做了个测试
addresscode字段索引,110多万条数据,执行下面语句
select count(addresscode) from rpgd.rp_people_bak_s where instr(addresscode,'370105',1)>0
用时110多秒!这效率太低了点吧
怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办

解决方案 »

  1.   

    addresscode建个instr函数索引
    如果还是慢的话 那就只要适应了
      

  2.   

    业务如何的?
    能否先用LIKE,然后再去去求 INSTR...
      

  3.   

    函数索引函数索引,快听到耳朵出茧子了,但是这个count语句完全跟函数索引没有关系啊!!!
      

  4.   

    如果addresscode有空值的话你在该字段建立不建立索引,系统都不会按照索引块来查找;你可以通过case when 先过滤掉该字段为空的记录数
    select count(addresscode) from rpgd.rp_people_bak_s where case when addresscode is not null then instr(addresscode,'370105',1)>0 end
    或者你把instr换成like '370105%' '%370105' 还是'%'370105%' ,这三个的查找域我不太记得了;你可以试试这两种方案
      

  5.   


    怎么没有关系?先根据instr(addresscode,'370105',1)>0条件来筛选,然后才count的!!
    所以,如果count(addresscode)出的记录数小于总记录数的25%,那么建立索引是有效的。
    建立函数索引:
    create index idx_instrcode on rpgd.rp_people_bak_s(instr(addresscode,'370105',1));
      

  6.   


    可是,addresscode这个查询参数是动态的啊,不可能每个值都建一个索引吧,就没有别的办法吗?我的直觉是,oracle不可能这么低性能的,我的服务器已经很顶尖了,很可能是我的oracle哪里配置出了问题
      

  7.   


    原来的语句就是 addresscode like '370105%',但是很多人说like不走索引,我换成了instr,依然不见效
      

  8.   

    --我不明白楼主的为什么这么慢
    --我的表300W数据,没有索引
    cost@COST> set autot on exp
    cost@COST> select count(*) from sf_rpt_ist_cell;  COUNT(*)
    ----------
       3003310已用时间:  00: 00: 01.81执行计划
    ----------------------------------------------------------
       0      SELECT STATEMENT Optimizer=CHOOSE
       1    0   SORT (AGGREGATE)
       2    1     TABLE ACCESS (FULL) OF 'SF_RPT_IST_CELL'cost@COST> select count(1) from sf_rpt_ist_cell;  COUNT(1)
    ----------
       3003310已用时间:  00: 00: 02.43执行计划
    ----------------------------------------------------------
       0      SELECT STATEMENT Optimizer=CHOOSE
       1    0   SORT (AGGREGATE)
       2    1     TABLE ACCESS (FULL) OF 'SF_RPT_IST_CELL'
      

  9.   

    即使建了索引,也要看选择性好坏,CBO才决定是不是使用索引。
    如果无法改变全表扫描的状况,就想办法改变IO状况,比如,并行读,多块读。
      

  10.   

    select count(addresscode) from rpgd.rp_people_bak_s where instr(addresscode,'370105',1)>0你是单独执行这个语句要110S?
      

  11.   

    是的是的!
    又有新发现!我另外建了一张表,只包含需要的字段,数据量一样!查询速度非常快了,秒级速度,难道字段多了会影响查询速度?
    贴出我的建表sql
    原表:
    create table RPGD.RP_PEOPLE_BAK_S
    (
      ADDRESSCODE   NVARCHAR2(15),
      FAMILYID      NVARCHAR2(36),
      BATCHID       NVARCHAR2(36),
      DYNAMICFORMID NVARCHAR2(36),
      PEOPLEINDEX   NUMBER(1),
      INNERSEQ      NUMBER(2),
      H1            NVARCHAR2(3),
      R1_1          NVARCHAR2(5),
      R1_2          NVARCHAR2(5),
      R2            NVARCHAR2(1),
      R3            NVARCHAR2(1),
      R4_1          NVARCHAR2(4),
      R4_2          NVARCHAR2(2),
      R5            NVARCHAR2(2),
      R6_1          NVARCHAR2(1),
      R6_2          NVARCHAR2(6),
      R7_1          NVARCHAR2(1),
      R7_2          NVARCHAR2(6),
      R8            NVARCHAR2(1),
      R9            NVARCHAR2(1),
      R10           NVARCHAR2(1),
      R11           NVARCHAR2(1),
      R12           NVARCHAR2(1),
      ISFRONT       NUMBER(1),
      PAGENUMBER    NUMBER(1),
      EXP1          NUMBER(1),
      EXP2          NUMBER(1),
      EXP3          NUMBER(1),
      EXP4          NUMBER(1),
      EXP5          NUMBER(1),
      EXP6          NUMBER(1),
      EXP7          NUMBER(1),
      EXP8          NUMBER(1),
      EXP9          NUMBER(1),
      EXP10         NUMBER(1),
      EXP11         NUMBER(1),
      EXP12         NUMBER(1),
      EXP13         NUMBER(1),
      EXP14         NUMBER(1),
      EXP15         NUMBER(1),
      EXP16         NUMBER(1),
      EXP17         NUMBER(1),
      EXP18         NUMBER(1),
      EXP19         NUMBER(1),
      EXP20         NUMBER(1),
      EXP21         NUMBER(1),
      EXP22         NUMBER(1),
      EXP23         NUMBER(1),
      EXP24         NUMBER(1),
      EXP25         NUMBER(1),
      EXP26         NUMBER(1),
      EXP27         NUMBER(1),
      EXP28         NUMBER(1),
      EXP29         NUMBER(1),
      EXP30         NUMBER(4)
    )
    tablespace USERS
      pctfree 10
      initrans 1
      maxtrans 255
      storage
      (
        initial 496M
        minextents 1
        maxextents unlimited
      );
    新表的:
    create table RPGD.RB
    (
      ADDRESSCODE NVARCHAR2(15),
      R4_1        NVARCHAR2(4),
      R4_2        NVARCHAR2(2),
      R6_1        NVARCHAR2(1),
      R6_2        NVARCHAR2(6),
      R7_1        NVARCHAR2(1),
      R7_2        NVARCHAR2(6),
      R8          NVARCHAR2(1),
      ID          NUMBER
    )
    tablespace USERS
      pctfree 10
      initrans 1
      maxtrans 255
      storage
      (
        initial 64K
        minextents 1
        maxextents unlimited
      );
      

  12.   

    有这情况分析下表  
    analyze  table rp_people_bak_s compute statistics以及整理碎片
    alter table rp_people_bak_s  move
    --重建索引
    alter index idxname rebuild
      

  13.   

    试试 统计信息出问题了....
    analyze  table rp_people_bak_s compute statistics
      

  14.   

    select count(addresscode) from rpgd.rp_people_bak_s where instr(addresscode,'370105',1)>0换成like '370105%'也不走索引的话,除了统计信息的问题,你这条sql返回多少数据呢?返回数据量过大的话也不会走索引
      

  15.   


    anylyze之后count是快了,但汇总语句执行还是慢,toad rebuild table之后,执行速度暴涨。太奇怪了,oracle维护真不是一般的费劲