请注意上面分析中的TABLE ACCESS(FULL)，这说明该语句执行了全表扫描。而且查询使用了21.38秒。这时表还没有经过分析。下面我们来对该表进行分析：
 
       　　
　　SQL> analyze table CASE_GA_AJZLZ compute statistics;
　　
表已分析。已用时间: 00: 05: 357.63。然后再来查询：
 
       　　
　　SQL> select count(*) from CASE_GA_AJZLZ;
　　COUNT(*)
　　----------
　　346639
　　
　　已用时间: 00: 00: 00.71
　　
　　Execution Plan
　
　　0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=351 Card=1)
　　1 0 SORT (AGGREGATE)
　　2 1 INDEX (FAST FULL SCAN) OF 'PK_AJZLZ' (UNIQUE) (Cost=351
　　Card=346351)
　　…………………………
　　
请注意，这次时间仅仅用了0.71秒！这要归功于INDEX(FAST FULL SCAN)。通过分析表，查询使用了PK_AJZLZ索引，磁盘I/O大幅减少，速度也大幅提升！下面的实用语句可以
　　
用来生成分析某个用户的所有表和索引，假设用户是GAXZUSR：
 
       　　
　　SQL> set pagesize 0
　　SQL> spool d:analyze_tables.sql;
　　SQL> select 'analyze table '||owner||'.'||table_name||'
compute statistics;' from dba_tables where owner='GAXZUSR';
　　SQL> spool off
　　SQL> spool spool d:analyze_indexes.sql;
　　SQL> select 'analyze index '||owner||'.'||index_name||'
compute statistics;' from dba_indexes where owner='GAXZUSR';
　　SQL> spool off
　　SQL> @d:analyze_tables.sql
　　SQL> @d:analyze_indexes.sql
　　
解释：上面的语句生成了两个sql文件，分别分析全部的GAXZUSR的表和索引。如果需要按照百分比来分析表，可以修改一下脚本。通过上面的步骤，我们就完成了对表和索引的分析，可以测试一下速度的改进啦。建议定期运行上面的语句，尤其是数据经过大量更新。
当然，也可以通过dbms_stats来分析表和索引，更方便一些。但是我仍然习惯上面的方法，因为成功与否会直接提示出来。
 
另外，我们可以将优化模式进行修改。optimizer_mode值可以是RULE、CHOOSE、FIRST_ROWS和ALL_ROWS。对于OLTP系统，可以改成FIRST_ROWS，来要求查询尽快返回结果。这样即使不用分析，在一般情况下也可以提高查询性能。但是表和索引经过分析后有助于找到最合适的执行计划。
三．设置cursor_sharing=FORCE 或SIMILAR
这种方法是8i才开始有的，oracle805不支持。通过设置该参数，可以强制共享只有文字不同的语句解释计划。例如下面两条语句可以共享：
 
       　　
　　SQL> SELECT * FROM MYTABLE WHERE NAME='tom'
　　SQL> SELECT * FROM MYTABLE WHERE NAME='turner'
　　
这个方法可以大幅降低缓冲区利用率低的问题，避免语句重新解释。通过这个功能，可以很大程度上解决硬解析带来的性能下降的问题。个人感觉可根据系统的实际情况，决定是否将该参数改成FORCE。该参数默认是exact。不过一定要注意，修改之前，必须先给ORACLE打补丁，否则改之后oracle会占用100%的CPU,无法使用。对于ORACLE9i，可以设置成SIMILAR，这个设置综合了FORCE和EXACT的优点。不过请慎用这个功能，这个参数也可能带来很大的负面影响！
四．将常用的小表、索引钉在数据缓存KEEP池中
内存上数据读取速度远远比硬盘中读取要快，