请各位帮我看一下，有关count在不同优化模式下的性能问题？

Question

我想关注一下你的rule模式下的执行计划(特别是 count(*) 和其他的差异)
这些都是无干扰相同情况下的多次测试么cost下估计都是  index fast  full scan 然后，你的
FREQ           NUMBER (6,2), 
  UAB            FLOAT (53), 
  UBC            FLOAT (53), 
  UCA            FLOAT (53))
这几个列是不是数据很少？恐怕你的表的数据量加起来还没有你的索引占的空间大  :)

Answer 1

to biti_rainy(biti_rainy) :
我又试了一次
发现在RULE模式下四条语句的执行计划都是
   0      SELECT STATEMENT Optimizer=RULE
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'TSUM_DATA_W'
cost下估计都是  index fast  full scan ，您说的没错
另
FREQ           NUMBER (6,2), 
  UAB            FLOAT (53), 
  UBC            FLOAT (53), 
  UCA            FLOAT (53))
四个列都有数据，另提供统计信息，在RULE模式下：
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       4660  consistent gets
       4652  physical reads
          0  redo size
        379  bytes sent via SQL*Net to client
        503  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
在CHOOSE模式下：
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       3367  consistent gets
       3355  physical reads
          0  redo size
        379  bytes sent via SQL*Net to client
        503  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed另再提供一个数据：
第一次测试COUNT（*）在RULE模式下用2.0s,以后就一直1.08s，为什么？望您能帮俺一把！

Answer 2

第一次测试COUNT（*）在RULE模式下用2.0s,以后就一直1.08s，:
这是因为第一次大量的io,以后数据保存在了内存中，所以这种测试，一定要在没有其他干扰的相同环境中多次测试，直到数据稳定！至于为什么full  table scan 比 index fast  full scan 快这是因为：
关于索引，你的索引键值太多，占行的比例太大，索引叶子长度是：  键值长度+ rowid 长度(18 字节)，然后索引还有树状结构等开销，这个百分比也不可忽略所以最后可能造成的原因就是索引的io比 full  table scan 还大！还有一个问题就是： 根据你的statistics来看，索引物理io似乎更少一些，但我不确信是不是因为所统计的块中 数据量的不一致。因为块中可能有很多空闲，不知道这个会否对 统计速度造成影响.或者，还是因为你都是只测试了一次造成的这样的结果。请每个测试均多次，报告出稳定的时间值和statistics来

Answer 3

biti_rainy 所言极是，请给他加分，结贴。

Answer 4

to biti_rainy(biti_rainy) :
我上面的测试都是多次的结果，
这个您放心，
时间值和statistics都比较稳定
我现在不明的就是：
为什么统计出来的物理IO索引的要少
却花费时间要长？
另您这句“根据你的statistics来看，索引物理io似乎更少一些，但我不确信是不是因为所统计的块中 数据量的不一致。因为块中可能有很多空闲，不知道这个会否对 统计速度造成影响.”
俺不明白！能再详细点吗？

Answer 5

关于你的这个问题
我没有测试难以确信，但一切都是猜测：如果你的表行长度很大，你再加一个 char(200) 这样的字段，估计索引扫描就应该快一些对于full scan来说，是从表的头扫描到尾(HWM)
对于索引，相临叶子节点之间存在着“指针”，也就是说做范围扫描的时候不用每次都从根扫描到叶子，但我不知道在范围扫描中这种结构会否带来计算的时间上的开销，这个开销有多大？尤其是你的两种扫描方式io差异不是特别大，那么在这种情况下什么因素占据主导，我无法确定。我只是猜测各种可能，因为尤其在差异比较小的情况下，任何一个环节的消息差异，在原来的经验中可以忽略掉的因素，可能突显出来