一、不要在索引列上调用Function

　　这样做将会阻止数据库使用这个索引，这个问题甚至可以影响这个分区表，因为这样做的话将不会从指定的分区中读取数据，而是扫描整一个表空间。对于大数据量的数据表，这将是性能上的一场大灾难。

　　不要这样做：

WHERETIME_ID+14 > to_number(to_char(sysdate,'J'))

　　应该这样做：

WHERETIME_ID > to_number(to_char(sysdate-14,'J'))

　二、使用Analyze对复杂SQL的优化

　　如果你不这样做，将意味着：你拒绝使用数据库的查询优化器，也失去了使用优化连接的机会。假设你创建了一张拥有100万条记录的临时表，如果不对其进 行分析，那么优化器将无法从现有的线索中获取表中真正的内容，于是它只能决定使用嵌套循环连接来一行行地扫描数据表，如果数据量不大，可能我们感觉不到性 能的损失，但是随着数据集的增长，你的数据库性能会越来越差。

　　建议这样做：

ANALYZE TABLE 
    
      COMPUTE STATISTICS
    

　三、将复杂的SQL分成几步执行

　　把SQL想象成披萨，我想你应该不会一下子将整个披萨吞到嘴里嚼烂它吧。

　　对于创建一个复杂的SQL查询，我们最好将其分成3-4个步骤，SQL越简单，优化器的效果就越好，另外，对每一张数据表中的数据也越容易调试。

　四、只有在必要的时候才使用Distinct

　　这是一个非常好的经验法则，Distinct经常被用在返回2条或2条以上重复记录的SQL查询中，使用Distinct，将会过滤掉重复的数据记 录。但是使用Distinct的目的一定要明确，当你确定返回的记录一定是唯一的时候才能使用，比如用户id。滥用Distinct将会出现不可预知的错 误，比如多表连接查询的情况。

　五、合理创建索引

　　最后一点就是合理创建表索引，简单来说，假如有一张10万条记录的数据表，你可能经常会查询这样的信息：“我的某个客户信息在这张表中吗？”。如果使用了索引，那么检索这条客户信息将非常迅速，否则数据库优化器将会选择全表扫描，这在大数据量的情况下简直就是噩梦。