为什么需要Analyze表

通过statspack, 我们发现有一个SQL比较占用资源。

  Buffer Gets    Executions  Gets per Exec  % Total  Hash Value
--------------- ------------ -------------- ------- ------------
     21,704,214        6,591        3,293.0    70.3   1183507389
select nvl(title,' ') ,nvl(punish_id,0) ,nvl(to_char(appeal_time
,'yyyy-mm-dd hh24:mi:ss'),' ') ,nvl(apeal_content,' ') ,ci_type
,nvl(ci_comment,' ') ,nvl(ci_ocs_id,0) ,nvl(commission_id,0) int
o :b0,:b1,:b2,:b3,:b4,:b5,:b6,:b7  from punishinfo_cs where ci_i
d=:b8

我们看到，每次执行，Oracle都需要读取3,293个Block，相当于25MB的数据量。

对这个SQL语句进行Explain Plan，我们发现，Oracle执行的是Full Table Scan。
我们看Explain相应的Cost， 发现为1。 我们检查数据字典，发现ci_id就是该表的主键。再查看数据字典，发现这个表是N久之前被Analyze过的了。所以Oracle 认为，这是个小表，执行全表扫描更加符合性能要求。

SQL> set timing on
SQL> select nvl(title,' ')  from punishinfo_cs where ci_id=45672;

NVL(TITLE,'')
--------------------------------------------------
阎王令

Elapsed: 00:00:00.26
通过SQLPLUS的Autotrace，我们看到：
      3295  consistent gets
2173        physical reads
大量的物理读取。

但是形式在变化，Oracle里面的数据也在变化：
SQL>  select count(*) from punishinfo_cs;

  COUNT(*)
----------
109245
我们可以看到，现在里面已经有11万的数据。执行全表扫描已经不是最优选择了。


我们对该表进行了Analyze，选择Compute方式：

SQL> analyze table PUNISHINFO_CS compute statistics;
   
Table analyzed.

Elapsed: 00:04:02.15
在进行了Analyze之后，我们再次执行原来的SQL：

  1*    select nvl(title,' ')  from punishinfo_cs where ci_id=45672
SQL> /

NVL(TITLE,'')
--------------------------------------------------
阎王令

Elapsed: 00:00:00.00

这个时候，速度已经从原来的0.25,降低到了小于0.01S.

转载于:https://www.cnblogs.com/zhaofei/p/3640729.html