oracle sql tuning 5--避免防范或者减少问题SQL

SQL语句这么容易出问题，能不能采取措施避免防范呢？

1.核查优化器的统计信息

查询优化器通过表，索引等的统计信息来决定使用那种执行计划.如果说统计信息没有被收集，或者说统计信息是过时的，不能代表数据库中最新的统计信息情况，那么优化器将没有足够的信息来生成好的执行计划.

大致可以通过以下两种方式核查

#1.收集部分表的统计信息，或者全部。这样对于那些使用表关联的语句有好处

#2.如果统计信息过时了，完全不能反映数据库现状的话，那么就需要重新收集。通过查看一个表现有的统计条数，在看统计信息中的条数是否一样，如果相差很远，那不用说了，统计信息肯定过时了.有用的视图有user_tables,dba_tables这里边都能看到表的条数，最后统计时间等信息

#3.评估执行计划

当在OLTP环境下调整SQL的时候，要尽量使少的数据流入到下一步操作中，如果下一步是一个表的关联，那么这就着只有少数行在参与关联。确认执行路径是否是最佳的

当检查执行计划时，可以关注下以下信息

The plan is such that the driving table has the best filter.我认为是驱动表应该被充分过虑

每一步的连接顺序应该满足一个总体条件，那就是，流入下一步的数据要尽可能减少

连接要适当，所谓适当就是返回数据的量不要太大。比如：nested loop joins 中用到了索引，这本来是好事，但是当返回的数据量很大时，这可能就不是最优的了

有效的使用视图,检查select列表，看访问视图是否是必要的

笛卡尔集不要出现，那怕是很小的表！

要让每个表被有效的访问

考虑语句中的关键词，表的记录数。查找可疑处，例如对于大表的FULL TABLE SCANS 。在WHERE条件中有关键词出现等。确定为什么SELECT语句没有使用索引.

全表扫描并不意味着效率不高，对于小表它更有用。如果说以上需要注意的地方都觉得有问题，那还是重写SQL吧！

当SQL问题太多，不得不重建SQL的时候...

通常重写无效SQL，比取调整它要来得容易，如果你理解语句的目的，那么写出符合要求的语句是很轻松的事

重建SQL可以考虑以下一些情况

#1.关联的时候尽量用=,and

#2.避免WHERE条件中有转换情况出现,如：

WHERE A.ORDER_NO =B.ORDER_NOd要好过

WHERE TO_NUMBER (SUBSTR(a.order_no, INSTR(b.order_no, '.') - 1))
= TO_NUMBER (SUBSTR(a.order_no, INSTR(b.order_no, '.') - 1))

在谓词或者WHERE条件中不要使用SQL函数，因为这种情况下优化器很有可能不能利用到索引,除去函数是基于索引的函数这种情况.

避免写不清楚的SQL，小心ORACLE的隐式转换，例如：当你想使用索引，在varchar2_col列上，你在条件中却写到  and varchar2_col = number_col[数字列]

这种情况下ORACLE会做什么呢，to_numbwr(varchar2_col)=number_col

避免复杂的表达式,例如：

col1 = NVL (:b1,col1)

NVL (col1,-999) = ….

TO_DATE(), TO_NUMBER(), 等
原因在于这种些表达式影响优化器选择基数，影响全局执行计划

 

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15720542/viewspace-629379/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15720542/viewspace-629379/