为什么需要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.
