以下的文章主要介绍的是Oracle SQL执行缓慢的分析问题描述，如果你是Oracle SQL执行实际应用方面的新手，你就可以通过以下的文章对Oracle SQL执行是如何正确使用的方法有一个更好的了解，以下就是文章的详细内容的介绍。

Oracle SQL执行缓慢的分析问题描述：

Oracle的优化器共有3种:

a. RULE (基于规则) b. COST (基于成本) c. CHOOSE (选择性)

设置缺省的优化器,可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS . 你当然也在SQL句级或是会话(session)级对其进行覆盖.

为了使用基于成本的优化器(CBO, Cost-Based Optimizer) , 你必须经常运行analyze 命令,以增加数据库中的对象统计信息(object statistics)的准确性.

如果数据库的优化器模式设置为选择性(CHOOSE),那么实际的优化器模式将和是否运行过analyze命令有关. 如果table已经被analyze过, 优化器模式将自动成为CBO , 反之,数据库将采用RULE形式的优化器.

在缺省情况下,Oracle采用CHOOSE优化器, 为了避免那些不必要的全表扫描(full table scan) , 你必须尽量避免使用CHOOSE优化器,而直接采用基于规则或者基于成本的优化器.

Oracle 数据库中一张表的数据已经2亿多，而且此表创建了4个独立的索引。由于业务需要，每天需分两次向此表中插入300万条记录。由于数据量大，每次插入耗时3个小时以上，严重影响效率。因此，修改了系统的算法，将此表中只存储当天新增记录。

将此表truncate后，第二天执行对此表的update操作时，非常耗时。表中有2亿多条数据的时候，此sql语句耗时59秒；表中有300万条数据的时候，此sql语句耗时几个小时。咨询DBA后，得出结论，需重建索引。重建后，6秒完成此操作。但第三天问题依然出现。DBA正在查找原因。难道每次truncate表，都需要重建索引？

对于这个问题，DBA也没有给出合理的解释，推测主要原因是Oracle复杂的查询优化算法。

最终，DBA给出的解决方案：

truncatetable.... 
dropindex..... 
insertdata..... 
createindex... 
analyzetabletable_namecomputestatistics; 

重新生成统计数据调整后，整个操作耗时非常少。