oracle性能优化操作的这几篇文章，是完全可以相互结合同时运用的。而且各种方法之间相互影响，紧密联系。

这种联系既存在一致性，也可能带来冲突，当冲突发生时，需要根据实际情况进行选择，没有固定的模式。

最后决定SQL优化功力的因素就是对ORACLE基础的掌握程度了。

另外，值得注意的是：随着时间的推移和数据的累计与变化，ORACLE对SQL语句的执行计划也会改变。

比如：基于代价的优化方法，随着数据量的增大，优化器可能错误的不选择索引而采用全表扫描。

这种情况可能是因为统计信息已经过时，在数据量变化很大后没有及时分析表；

但如果对表进行分析之后，仍然没有用上合理的索引，那么就有必要对SQL语句用HINT提示，强制用合理的索引。

但这种HINT提示也不能滥用，因为这种方法过于复杂，缺乏通用性和应变能力，同时也增加了维护上的代价；

相对来说，基于函数右移、去掉“IN ，OR ，<> ，IS NOT NULL ”、分解复杂的SQL语句等等方法，却是“放之四海皆准”的，

可以放心大胆的使用。

同时，优化也不是“一劳永逸”的，必须随着情况的改变进行相应的调整。

当数据库设计发生变化，包括更改表结构：字段和索引的增加、删除或改名等；

业务逻辑发生变化：如查询方式、取值范围发生改变等等。

在这种情况下，也必须对原有的优化进行调整，以适应效率上的需求。

oracle 性能优化操作：总结