指定索引查询为什么没全表扫描快

棉花糖ONE · 发表于 2007-12-3 10:45

巴乔的例子挺眼熟的

mget · 发表于 2007-12-3 11:06

原帖由 blue_prince 于 2007-12-2 23:46 发表
另外，如果不是数据仓库环境的数据库，不建议对表或者索引设置并行度，不会带来什么好处，有可能会更大程度上地影响到性能
SQL> select  /*+ full(disorganized)*/ *
  2  from disorganized
  3  where x between 20000 and 40000
  4  /

20001 rows selected.

Elapsed: 00:00:01.00

Execution Plan
----------------------------------------------------------
0    SELECT STATEMENT Optimizer=CHOOSE (Cost=105 Card=220 Bytes=2
      23300)

1 0 TABLE ACCESS (FULL) OF 'DISORGANIZED' (Cost=105 Card=220 By
      tes=223300)
Statistics
----------------------------------------------------------
      60  recursive calls
      0  db block gets
   2408  consistent gets
      0  physical reads
      0  redo size
1805701  bytes sent via SQL*Net to client
   15166  bytes received via SQL*Net from client
   1335  SQL*Net roundtrips to/from client
      2  sorts (memory)
      0  sorts (disk)
   20001  rows processed

上面哪个0 physical reads，表明数据都在内存中，如果清理一下内存是否速度不一样呢？

另外
我知道，如果表有碎片可以通过move来整理解决，如果是数据存放的不顺序，那么我问一下，既然是数据分配的问题，那么通过什么办法能让其数据整理规范出来呢？

blue_prince · 发表于 2007-12-3 12:24

原帖由 棉花糖ONE 于 2007-12-3 10:45 发表
巴乔的例子挺眼熟的

tom书中的例子，当时看书时记的笔记

blue_prince · 发表于 2007-12-3 12:27

原帖由 mget 于 2007-12-3 11:06 发表

上面哪个0 physical reads，表明数据都在内存中，如果清理一下内存是否速度不一样呢？

另外
我知道，如果表有碎片可以通过move来整理解决，如果是数据存放的不顺序，那么我问一下，既然是数据分配的问 ...

清理内存当然速度会更慢了，还得物理读。表的数据你当然可以根据自己的意愿来整理，前提是这样做必要性大不大？毕竟以后INSERT的数据你又无法控制了。又得定期花时间做这个无意义的事。

mget · 发表于 2007-12-3 20:55

原帖由 blue_prince 于 2007-12-3 12:24 发表

tom书中的例子，当时看书时记的笔记

刚翻了一下tom 的书,在索引一章看到了这段话,但是我不明白的是,对于Oracle应该知道有这样的问题,碰到大数据量索引的数据,为什么不考虑排序并合并一下结果再去扫描数据块呢,那怕提供一个HINT的暗示让他这么做也好啦!

mget · 发表于 2007-12-3 23:26

另外,对于数据不规范是否应该用dbms_stats的如下参数分析呢
Method_Opt => 'FOR ALL INDEXED COLUMNS SIZE SKEWONLY ',--高度倾斜的索引(某些值的行数不对称)方式

yh2ygy · 发表于 2007-12-4 02:36

I have seen many times a fts query ran faster than index-based query when return less than 10% but more than 1% result compares to whole table rows

blue_prince · 发表于 2007-12-5 09:38

原帖由 mget 于 2007-12-3 23:26 发表
另外,对于数据不规范是否应该用dbms_stats的如下参数分析呢
Method_Opt => 'FOR ALL INDEXED COLUMNS SIZE SKEWONLY ',--高度倾斜的索引(某些值的行数不对称)方式

可以考虑使用这样的分析方法分析