oracle性能优化操作的这几篇文章,是完全可以相互结合同时运用的。而且各种方法之间相互影响,紧密联系。
这种联系既存在一致性,也可能带来冲突,当冲突发生时,需要根据实际情况进行选择,没有固定的模式。
最后决定SQL优化功力的因素就是对ORACLE基础的掌握程度了。
另外,值得注意的是:随着时间的推移和数据的累计与变化,ORACLE对SQL语句的执行计划也会改变。
比如:基于代价的优化方法,随着数据量的增大,优化器可能错误的不选择索引而采用全表扫描。
这种情况可能是因为统计信息已经过时,在数据量变化很大后没有及时分析表;
但如果对表进行分析之后,仍然没有用上合理的索引,那么就有必要对SQL语句用HINT提示,强制用合理的索引。
但这种HINT提示也不能滥用,因为这种方法过于复杂,缺乏通用性和应变能力,同时也增加了维护上的代价;
相对来说,基于函数右移、去掉“IN ,OR ,<> ,IS NOT NULL ”、分解复杂的SQL语句等等方法,却是“放之四海皆准”的,
可以放心大胆的使用。
同时,优化也不是“一劳永逸”的,必须随着情况的改变进行相应的调整。
当数据库设计发生变化,包括更改表结构:字段和索引的增加、删除或改名等;
业务逻辑发生变化:如查询方式、取值范围发生改变等等。
在这种情况下,也必须对原有的优化进行调整,以适应效率上的需求。