引发大家的一个思考

zjxs

最初由 fjtzg 发布
[B]环境1：
   2    1     INDEX (FAST FULL SCAN) OF 'IND_RKXX_PERSONID' (NON-UNIQUE) (Cost=1777 Card=2808040)

环境2：
   2    1     INDEX (FAST FULL SCAN) OF 'PK_PERSONPHOTO' (UNIQUE) (Cos t=4 Card=4355889)

[/B]

CBO分析两者的IINDEX FFS的COST差异很大，可能索引的存储存在较大的差异，可以把两个索引的统计信息贴上来看看。

另外，已经知道哪个SQL有问题，可以直接用sql trace（level 8）来分析好了

fjtzg

环境1

fjtzg

环境2

fjtzg

环境1和环境2所测试的表结构相同，记录数不同

blue_prince10

你现在相同的表再执行一下看看，还有初始化参数也贴上来看看，第二次不具可比性，因为记录还没上来，发生了物理读。

rollingpig

HWM ?

blue_prince10

他没FTS，跟HWM应该没关系吧

fjtzg

SQL> select count(personid) from rktx;

COUNT(PERSONID)
---------------
        3529142

已用时间:  00: 00: 26.07

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1)
   1    0   SORT (AGGREGATE)
   2    1     INDEX (FAST FULL SCAN) OF 'PK_PERSONPHOTO' (UNIQUE) (Cos
          t=4 Card=3529142)





Statistics
----------------------------------------------------------
          0  recursive calls
         30  db block gets
      17273  consistent gets
          0  physical reads
          0  redo size
        203  bytes sent via SQL*Net to client
        128  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

fjtzg

最初由 blue_prince10 发布
[B]你现在相同的表再执行一下看看，还有初始化参数也贴上来看看，第二次不具可比性，因为记录还没上来，发生了物理读。 [/B]

确实如此，但是此次数据上来，没发生物理读，可时间还是很长呢！

blue_prince10

你的内存是怎么分配的？做个SQL TRACE看一下