其实我刚才已经发帖求助了,就是那个十万火急的帖子,但是没有找到答案,另外我又做了个测试
addresscode字段索引,110多万条数据,执行下面语句
select count(addresscode) from rpgd.rp_people_bak_s where instr(addresscode,'370105',1)>0
用时110多秒!这效率太低了点吧
怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办
addresscode字段索引,110多万条数据,执行下面语句
select count(addresscode) from rpgd.rp_people_bak_s where instr(addresscode,'370105',1)>0
用时110多秒!这效率太低了点吧
怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办怎么办
如果还是慢的话 那就只要适应了
能否先用LIKE,然后再去去求 INSTR...
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%' ,这三个的查找域我不太记得了;你可以试试这两种方案
怎么没有关系?先根据instr(addresscode,'370105',1)>0条件来筛选,然后才count的!!
所以,如果count(addresscode)出的记录数小于总记录数的25%,那么建立索引是有效的。
建立函数索引:
create index idx_instrcode on rpgd.rp_people_bak_s(instr(addresscode,'370105',1));
可是,addresscode这个查询参数是动态的啊,不可能每个值都建一个索引吧,就没有别的办法吗?我的直觉是,oracle不可能这么低性能的,我的服务器已经很顶尖了,很可能是我的oracle哪里配置出了问题
原来的语句就是 addresscode like '370105%',但是很多人说like不走索引,我换成了instr,依然不见效
--我的表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'
如果无法改变全表扫描的状况,就想办法改变IO状况,比如,并行读,多块读。
又有新发现!我另外建了一张表,只包含需要的字段,数据量一样!查询速度非常快了,秒级速度,难道字段多了会影响查询速度?
贴出我的建表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
);
analyze table rp_people_bak_s compute statistics以及整理碎片
alter table rp_people_bak_s move
--重建索引
alter index idxname rebuild
analyze table rp_people_bak_s compute statistics
anylyze之后count是快了,但汇总语句执行还是慢,toad rebuild table之后,执行速度暴涨。太奇怪了,oracle维护真不是一般的费劲