select a,b,c,count(*) from table1 where rq<to_date('2004.1.1','yyyy.mm.dd') group by a,b,c
rq有索引,查询时间810秒
目前考虑
1、增加sort_area_size 20M
2、建立符合索引rq,a,b,c,觉得不可能。但是,这样可以大大提高速度,耗时在30多秒。
3、增大databuffer
4、增加VEH_INDEX1表空间于不同的驱动器,提高I/O
5、db_file_multiblock_read_count 由8增大到16,提高读取的速度执行计划如下:
SELECT STATEMENT, GOAL = CHOOSE
SORT GROUP BY
TABLE ACCESS BY INDEX ROWID table1 这儿的耗时是最多的。
INDEX RANGE SCAN table_rq 还有其他地方要考虑吗?
rq有索引,查询时间810秒
目前考虑
1、增加sort_area_size 20M
2、建立符合索引rq,a,b,c,觉得不可能。但是,这样可以大大提高速度,耗时在30多秒。
3、增大databuffer
4、增加VEH_INDEX1表空间于不同的驱动器,提高I/O
5、db_file_multiblock_read_count 由8增大到16,提高读取的速度执行计划如下:
SELECT STATEMENT, GOAL = CHOOSE
SORT GROUP BY
TABLE ACCESS BY INDEX ROWID table1 这儿的耗时是最多的。
INDEX RANGE SCAN table_rq 还有其他地方要考虑吗?
增大
db_block_buffers
建立的索引group by a,b,c符合了的用途!
不错,关注高手!
但是考虑表分区,我觉得速度上应该不会影响很大!
都是便于检索某一段数据时,不需要 index scans ,直接顺序读取数据块
对于那些行长度比较小的表来说,会比较好
如果不建索引rq,a,b,c.
别的任何办法,都不能根本上解决问题.
将记录Archive到别的表上吧.
rq<to_date('2004.1.1','yyyy.mm.dd') 的纪录超过总纪录数的20%,那就应该选择full table scan而不是index scan。在多cpu服务器上,使用parallel能极大地提高速度。下面是我测试的结果:
1.) full index scan
11:25:12 SQL> select count(*) from fcst_eu;
COUNT(*)
----------
145316637
Elapsed: 00:06:32.032). full table scan + parallel
11:39:51 SQL> select /*+ parallel(x 24) full(x) */ count(*) from fcst_eu x
COUNT(*)
----------
145316637
Elapsed: 00:00:57.87
1、bzszp(SongZip): 重新按照日期建立表,如何实现?
2、 KingSunSha(弱水三千) :select /*+ parallel(x 24) full(x) */ count(*) from fcst_eu x解释下/*+ parallel(x 24) full(x) */ 什么意思?
大家继续讨论。
是通过create table newtablename as select * from oldtablename order by rq;
2、 KingSunSha(弱水三千) :select /*+ parallel(x 24) full(x) */ count(*) from
fcst_eu x
是建议数据采用全扫描的方式进行查询!
如果cache到内存中,应该如何实现?会影响对表的修改操作吗?
CCDJRQ<to_date('2004-06-20','yyyy/mm/dd')+1 and
not (ZT like '%B%' or ZT like '%E%' or ZT like '%M%') and clly='1' group by xzqh,cllx,syxz
看了执行计划怎么还是使用日期index索引呢
如果做一般的插入删除,数据会写盘吗,还是关闭数据库最后写盘呢?
按索引组织同时索引rq,a,b,c
24代表分为24个线程吧,好像是这个意思来者。