oracle sql优化指导,Oracle 10g SQL 优化再学习

从8i到10g，Oracle不断进化自己的SQL Tuning智能，一些秘籍级的优化口诀已经失效。

但我喜欢失效，不用记口诀，操个Toad for Oracle Xpert

，按照大方向舒舒服服的

调优才是爱做的事情。

1.Excution Plan

Excution

Plan是最基本的调优概念，不管你的调优吹得如何天花乱堕，结果还是要由Excution plan来显示Oracle

最终用什么索引、按什么顺序连接各表，Full Table Scan还是Access by Rowid

Index，瓶颈在什么地方。如果没有它的指导，一切调优都是蒙的。

2.Toad for Oracle

Xpert

用它来调优在真的好舒服。Quest

吞

并了Lecco后，将它整合到了Toad 的SQL

Tunning里面：最清晰的执行计划显示，自动生成N条等价SQL、给出优化建议，不同SQL执行计划的对比，还有实际执行的逻辑读、物理读数据等等一

目了然。

3.索引

大部分的性能问题其实都是索引应用的问题，Where子句、

Order By、Group By 都要用到索引。

一般开发人员认为将索引建全了就可以下班回家了，实则还有颇多的思量和陷阱。

3.1

索引列上不要进行计算

这是最最普遍的失效陷阱，比如where

trunc(order_date)=trunc(sysdate),

i+2>4。索引失效的原因也简单，索引是针对原值建的二叉树，你将列值*3/4+2折腾一番后，原来的二叉树当然就用不上了。解决的方法:

1.　换成等价语法，比如trunc(order_date) 换成

where order_date

>

trunc(sysdate)

-

1

and

order_date

<

trunc(sysdate)

+

1

2.    特别为计算建立函数索引

create

index

Ｉ_XXXX

on

shop_order(trunc(order_date))

3.    将计算从等号左边移到右边

这是针对某些无心之失的纠正，把a*2>4　改为a>4/2；把

TO_CHAR(zip) = '94002' 改为zip = TO_NUMBER('94002');

3.2

CBO与索引选择性

建了索引也不一定会被Oracle用的，就像个挑食的孩子。基于成本的优化器(CBO,

Cost-Based Optimizer)，会先看看表的大小，还有索引的重复度，再决定用还是不用。表中有100 条记录而其中有80

个不重复的索引键值. 这个索引的选择性就是80/100 =

0.8，留意Toad里显示索引的Selective�