细说SQL性能优化

1：在进行多表关联时，多用where语句把单个表的结果集最小化，多用聚合函数汇总结果集后再与其它表做关联，以使结果集数据量最小化
2：在两张表进行关联时，应考虑可否使用右连接。以提高查询速度
3：使用where而不是having，where是用于过滤行的，而having是用来过滤组的，因为行被分组后，having 才能过滤组，所以尽量用户where过滤
4：使用exists而不用in因为exists 只检查行的存在，而in检查实际值。
5：in操作符
用in写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。
但是用in的SQL性能总是比较低，原因是：
对于用in的SQL语句Oracle总是试图将其转换成多个表的连接，如果转换不成功则先执行in
里面的子查询，再查询外层的表记录
如果转换成功就转换成多个表的连接。因此 不管理怎么，用in的SQL语句总是多了一个转换的
过程。一般的SQL都可以转换成功。
但对于含有分组统计等方面的SQL就不能转换了。因此在业务密集的SQL当中尽量不采用in操作符。
6：not in操作符
此操作强烈推荐不使用，因为其不能应用表的索引。
如遇这种情况，应该用exists ，not exists 或者（外连接+判断为空）方案代替。
7：<> 操作符
不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。
对于这种情况，可以用其它方式代替，如：
A<>0 -> A>0 or A<0
A<>'' -> A>''
8：like 操作符
遇到 需要用到like过滤的SQL语句，完全可以用instr代替。处理速度将显著提高。
9：union操作符
union在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，
删除重复的记录再返回结果。实际大部分应用中是不会产生重复的记录，最常见的是过程表与历史
表union。如：
select * from gc_dfys
union
select * from ls_jg_dfys
这个SQL在运行时先取出两个表的结果，再用排序空间进行排序删除重复的记录，最后返回结果集，
如果表数据量大的话可能会导致用磁盘进行排序。
推荐方案：采用union all操作符替代union，因为union all操作只是简单的将两个结果合并后就返回。
select * from gc_dfys
union all
select * from ls_jg_dfys
10 SQL书写的影响
同一功能同一性能不同写法SQL的影响
如一个SQL在A程序员写的为
select * from zl_yhjbqk
B程序员写的为
select * from dlyx.zl_yhjbqk（带表所有者的前缀）
C程序员写的为
select * from DLYX.ZLYHJBQK（大写表名）
D程序员写的为
select * from DLYX.ZLYHJBQK（中间多了空格）
以上四个SQL在Oracle分析整理之后产生的结果及执行的时间是一样的，但是从Oracle共享内存SGA的原理，可以得出Oracle对每个SQL都会对其进行一次分析，并且占用共享内存，如果将SQL的字符串及格式写得完全相同则Oracle只会分析一次，共享内存也只会留下一次的分析结果，这不仅可以减少分析SQL的时间，而且可以减少共享内存重复的信息，Oracle也可以准确统计SQL的执行频率。
11:where后面的条件顺序影响
where子句后面的条件顺序对大数据量表的查询会产生直接的影响，如
select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1KV以下'
以上两个SQL中dy_dj（电压等级）及xh_bz（销户标志）两个字段都没进行索引，所以执行的时候都
是全表扫描，
第一条SQL的dy_dj = '1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，
在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的比较，而在进行第二条SQL的时候0.5%条记录
都进行dy_dj及xh_bz的比较，
以此可以得出第二条SQL的CPU占用率明显比第一条低。
12:询表顺序的影响
在from后面的表中的列表顺序会对SQL执行性能影响，在没有索引及Oracle没有对表进行统计分析的
情况下Oracle会按表出现的顺序进行链接，
由此因为表的顺序不对会产生十分耗服务器资源的数据交叉。（注：如果对表进行了统计分析，
Oracle会自动先进小表的链接，再进行大表的链接）
13:采用函数处理的字段不能利用索引，如：
substr(hbs_bh,1,4)='5400'，优化处理：hbs_bh like '5400%'
trunc(sk_rq)=trunc(sysdate)，优化处理：
sk_rq>=trunc(sysdate) and sk_rq<trunc(sysdate+1)
进行了显式或隐式的运算的字段不能进行索引，如：
ss_df+20>50，优化处理：ss_df>30
'X'||hbs_bh>'X5400021452'，优化处理：hbs_bh>'5400021542'
sk_rq+5=sysdate，优化处理：sk_rq=sysdate-5
hbs_bh=5401002554，优化处理：hbs_bh=' 5401002554'，注：此条件对hbs_bh 进行隐式的
to_number转换，因为hbs_bh字段是字符型。
条件内包括了多个本表的字段运算时不能进行索引，如：
ys_df>cx_df，无法进行优化
qc_bh||kh_bh='5400250000'，优化处理：qc_bh='5400' and kh_bh='250000'
14:应用Oracle的HINT（提示）处理
提示处理是在Oracle产生的SQL分析执行路径不满意的情况下要用到的。它可以对SQL进行以下方
面的提示
目标方面的提示：
COST（按成本优化）
RULE（按规则优化）
CHOOSE（缺省）（Oracle自动选择成本或规则进行优化）
select empno,ename,hiredate from emp where empno='SCOTT';
all_ROWS（所有的行尽快返回）
select empno,ename,hiredate from emp where empno='SCOTT';
FIRST_ROWS（第一行数据尽快返回）
select *
from xxx
where xxx;
select *
from xxx
where xxx
优化器提示：用它的目的是提高SQL语句的响应时间，快速的先返回n行。
访问路径的提示
FULL: 执行全表扫描
ROID: 根据ROWID进行扫描
INDEX: 根据某个索引进行扫描
select * from emp where deptno=200 and sal>300;
如果写了多个，则Oracle自动选择最优的哪个
select * from emp where deptno=200 and sal>300;
INDEX_JOIN: 如果所选的字段都是索引字段(是几个索引的)，那么可以通过索引连接就可访问到数据，而不需要访问表的数据。
select deptno,sal from emp;
where deptno=20;
INDEX_FFS: 执行快速全索引扫描
select count(*) from emp;
NO_INDEX: 指定不使用哪些索引
select * from emp where deptno=200 and sal>300;
and_EQUAL: 指定合并两个或以上索引检索的结果(交集)，最多不能超过5个
执行方法的提示：
USE_NL（使用NESTED LOOPS方式联合）
USE_MERGE（使用MERGE join方式联合）
USE_HASH（使用HASH join方式联合）
根据表出现在from中的顺序,orderED使Oracle依此顺序对其连接.
例如:
select A.col1,B.col2,C.col3 from table1 A,table2 B,table3 C
where A.col1=B.col1 and B.col1=C.col1;
将指定表与嵌套的连接的行源进行连接,并把指定表作为内部表.
例如:
select dept.deptno,emp.empno,emp.ename
from emp,dept where emp.deptno=dept.deptno;
将指定的表与其他行源通过合并排序连接方式连接起来.
例如:
select * from emp,dept
where emp.deptno=dept.deptno;
将指定的表与其他行源通过哈希连接方式连接起来.
例如:
select * from emp,dept
where emp.deptno=dept.deptno;
其它高级提示（如并行处理等等）
有时如果出于成本方面的考虑Oracle也可能不会按提示进行。根据实践应用，一般不建议开发人员应用Oracle提示，
因为各个数据库及服务器性能情况不一样，很可能一个地方性能提升了，但另一个地方却下降了，
Oracle在SQL执行分析方面已经比较成熟，如果分析执行的路径不对首先应在数据库结构（主要是索引）、
服务器当前性能（共享内存、磁盘文件碎片）、数据库对象（表、索引）统计信息是否正确这几方面分析。
一、问题的提出
在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的SQL语句，提高系统的可用性。
在多数情况下，Oracle使用索引来更快地遍历表，优化器主要根据定义的索引来提高性能。但是，如果在SQL语句的where子句中写的SQL代码不合理，就会造成优化器删去索引而使用全表扫描，一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种原则来删除索引，这有助于写出高性能的SQL语句。
二、SQL语句编写注意问题
下面就某些SQL语句的where子句编写中需要注意的问题作详细介绍。在这些where子句中，即使某些列存在索引，但是由于编写了劣质的SQL，系统在运行该SQL语句时也不能使用该索引，而同样使用全表扫描，这就造成了响应速度的极大降低。
1. 操作符优化
(a)in操作符
用in写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。但是用in的SQL性能总是比较低的，从Oracle执行的步骤来分析用in的SQL与不用in的SQL有以下区别：
Oracle试图将其转换成多个表的连接，如果转换不成功则先执行in里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。由此可见用in的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。
推荐方案：在业务密集的SQL当中尽量不采用in操作符，用exists 方案代替。
(b) not in操作符
此操作是强列不推荐使用的，因为它不能应用表的索引。
推荐方案：用notexists 方案代替
(c) is null 或is not null操作（判断字段是否为空）
判断字段是否为空一般是不会应用索引的，因为索引是不索引空值的。不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。任何在where子句中使用is null或is not null的语句优化器是不允许使用索引的。
推荐方案：用其它相同功能的操作运算代替，如：a is not null 改为 a>0 或a>''等。不允许字段为空，而用一个缺省值代替空值，如申请中状态字段不允许为空，缺省为申请。
(d) > 及 < 操作符（大于或小于操作符）
大于或小于操作符一般情况下是不用调整的，因为它有索引就会采用索引查找，但有的情况下可以对它进行优化，如一个表有100万记录，一个数值型字段A，30万记录的A=0，30万记录的A=1，39万记录的A=2，1万记录的A=3。那么执行A>2与A>=3的效果就有很大的区别了，因为A>2时Oracle会先找出为2的记录索引再进行比较，而A>=3时Oracle则直接找到=3的记录索引。
(e) LIKE操作符
LIKE操作符可以应用通配符查询，里面的通配符组合可能达到几乎是任意的查询，但是如果用得不好则会产生性能上的问题，如LIKE '%5400%' 这种查询不会引用索引，而LIKE 'X5400%'则会引用范围索引。
一个实际例子：用YW_YHJBQK表中营业编号后面的户标识号可来查询营业编号 YY_BHlike'%5400%' 这个条件会产生全表扫描，如果改成YY_BHlike'X5400%' or YY_BHlike'B5400%' 则会利用YY_BH的索引进行两个范围的查询，性能肯定大大提高。
带通配符(%)的like语句：
同样以上面的例子来看这种情况。目前的需求是这样的，要求在职工表中查询名字中包含cliton的人。可以采用如下的查询SQL语句:
select * from employee where last_name like '%cliton%';
这里由于通配符(%)在搜寻词首出现，所以Oracle系统不使用last_name的索引。在很多情况下可能无法避免这种情况，但是一定要心中有底，通配符如此使用会降低查询速度。然而当通配符出现在字符串其他位置时，优化器就能利用索引。在下面的查询中索引得到了使用:
select * from employee where last_name like 'c%';
(f) union操作符
union在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。实际大部分应用中是不会产生重复的记录，最常见的是过程表与历史表union。如：
select * from gc_dfys
union
select * from ls_jg_dfys
这个SQL在运行时先取出两个表的结果，再用排序空间进行排序删除重复的记录，最后返回结果集，如果表数据量大的话可能会导致用磁盘进行排序。
推荐方案：采用union all操作符替代union，因为union all操作只是简单的将两个结果合并后就返回。
select * from gc_dfys
union all
select * from ls_jg_dfys
(g) 联接列
对于有联接的列，即使最后的联接值为一个静态值，优化器是不会使用索引的。我们一起来看一个例子，假定有一个职工表(employee)，对于一个职工的姓和名分成两列存放(FIRST_NAME和LAST_NAME)，现在要查询一个叫比尔.克林顿(Bill Cliton)的职工。
下面是一个采用联接查询的SQL语句：
select * from employss where first_name||''||last_name ='Beill Cliton';
上面这条语句完全可以查询出是否有Bill Cliton这个员工，但是这里需要注意，系统优化器对基于last_name创建的索引没有使用。当采用下面这种SQL语句的编写，Oracle系统就可以采用基于last_name创建的索引。
*** where first_name ='Beill' and last_name ='Cliton';
(h) order by语句
order by语句决定了Oracle如何将返回的查询结果排序。order by语句对要排序的列没有什么特别的限制，也可以将函数加入列中(象联接或者附加等)。任何在order by语句的非索引项或者有计算表达式都将降低查询速度。
仔细检查order by语句以找出非索引项或者表达式，它们会降低性能。解决这个问题的办法就是重写order by语句以使用索引，也可以为所使用的列建立另外一个索引，同时应绝对避免在order by子句中使用表达式。
(i) not
我们在查询时经常在where子句使用一些逻辑表达式，如大于、小于、等于以及不等于等等，也可以使用and(与)、or(或)以及not(非)。not可用来对任何逻辑运算符号取反。下面是一个not子句的例子:
... where not (status ='VALID')
如果要使用not，则应在取反的短语前面加上括号，并在短语前面加上not运算符。not运算符包含在另外一个逻辑运算符中，这就是不等于(<>)运算符。换句话说，即使不在查询where子句中显式地加入not词，not仍在运算符中，见下例:
... where status <>'inVALID';
对这个查询，可以改写为不使用not：
select * from employee where salary<3000 or salary>3000;
虽然这两种查询的结果一样，但是第二种查询方案会比第一种查询方案更快些。第二种查询允许Oracle对salary列使用索引，而第一种查询则不能使用索引。
2. SQL书写的影响
(a) 同一功能同一性能不同写法SQL的影响。
如一个SQL在A程序员写的为 select * from zl_yhjbqk
B程序员写的为 select * from dlyx.zl_yhjbqk（带表所有者的前缀）
C程序员写的为 select * from DLYX.ZLYHJBQK（大写表名）
D程序员写的为 select * from DLYX.ZLYHJBQK（中间多了空格）
以上四个SQL在Oracle分析整理之后产生的结果及执行的时间是一样的，但是从Oracle共享内存SGA的原理，可以得出Oracle对每个SQL 都会对其进行一次分析，并且占用共享内存，如果将SQL的字符串及格式写得完全相同，则Oracle只会分析一次，共享内存也只会留下一次的分析结果，这不仅可以减少分析SQL的时间，而且可以减少共享内存重复的信息，Oracle也可以准确统计SQL的执行频率。
(b) where后面的条件顺序影响
where子句后面的条件顺序对大数据量表的查询会产生直接的影响。如：
select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1KV以下'
以上两个SQL中dy_dj（电压等级）及xh_bz（销户标志）两个字段都没进行索引，所以执行的时候都是全表扫描，第一条SQL的dy_dj = '1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的比较，而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较，以此可以得出第二条SQL的CPU占用率明显比第一条低。
(c) 查询表顺序的影响
在from后面的表中的列表顺序会对SQL执行性能影响，在没有索引及Oracle没有对表进行统计分析的情况下，Oracle会按表出现的顺序进行链接，由此可见表的顺序不对时会产生十分耗服物器资源的数据交叉。（注：如果对表进行了统计分析，Oracle会自动先进小表的链接，再进行大表的链接）
3. SQL语句索引的利用
(a) 对条件字段的一些优化
采用函数处理的字段不能利用索引，如：
substr(hbs_bh,1,4)='5400'，优化处理：hbs_bh like '5400%'
trunc(sk_rq)=trunc(sysdate)， 优化处理：sk_rq>=trunc(sysdate) and sk_rq
进行了显式或隐式的运算的字段不能进行索引，如：ss_df+20>50，优化处理：ss_df>30
'X' || hbs_bh>'X5400021452'，优化处理：hbs_bh>'5400021542'
sk_rq+5=sysdate，优化处理：sk_rq=sysdate-5
hbs_bh=5401002554，优化处理：hbs_bh=' 5401002554'，注：此条件对hbs_bh 进行隐式的to_number转换，因为hbs_bh字段是字符型。
条件内包括了多个本表的字段运算时不能进行索引，如：
ys_df>cx_df，无法进行优化
qc_bh || kh_bh='5400250000'，优化处理：qc_bh='5400' and kh_bh='250000'
4. 更多方面SQL优化资料分享
（1） 选择最有效率的表名顺序(只在基于规则的优化器中有效)：
Oracle 的解析器按照从右到左的顺序处理from子句中的表名，from子句中写在最后的表(基础表 driving table)将被最先处理，在from子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表.
（2） where子句中的连接顺序：
Oracle采用自下而上的顺序解析where子句,根据这个原理,表之间的连接必须写在其他where条件之前, 那些可以过滤掉最大数量记录的条件必须写在where子句的末尾.
（3） select子句中避免使用 ' * '：
Oracle在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间。
（4） 减少访问数据库的次数：
Oracle在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变量 , 读数据块等。
（5） 在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加每次数据库访问的检索数据量 ,建议值为200。
（6） 使用DECODE函数来减少处理时间：
使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表.
（7） 整合简单,无关联的数据库访问：
如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使它们之间没有关系) 。
（8） 删除重复记录：
最高效的删除重复记录方法 ( 因为使用了ROWID)例子：
delete from emp E where E.ROWID > (select min(X.ROWID) from emp X where X.empno = E.empno)。
（9）用truncate替代delete：
当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) 用来存放可以被恢复的信息. 如果你没有commit事务,Oracle会将数据恢复到删除之前的状态(准确地说是恢复到执行删除命令之前的状况) 而当运用truncate时, 回滚段不再存放任何可被恢复的信息.当命令运行后,数据不能被恢复.因此很少的资源被调用,执行时间也会很短. (译者按: truncate只在删除全表适用,truncate是DDL不是DML) 。
（10）尽量多使用commit：
只要有可能,在程序中尽量多使用commit, 这样程序的性能得到提高,需求也会因为commit所释放的资源而减少，commit所释放的资源:
a. 回滚段上用于恢复数据的信息.
b. 被程序语句获得的锁
c. redo log buffer 中的空间
d. Oracle为管理上述3种资源中的内部花费
（11）用where子句替换having子句：
避免使用having子句, having 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序,总计等操作. 如果能通过where子句限制记录的数目,那就能减少这方面的开销. (非oracle中)on、where、having这三个都可以加条件的子句中，on是最先执行，where次之，having最后，因为on是先把不符合条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，where也应该比having快点的，因为它过滤数据后才进行sum，在两个表联接时才用on的，所以在一个表的时候，就剩下where跟having比较了。在这单表查询统计的情况下，如果要过滤的条件没有涉及到要计算字段，那它们的结果是一样的，只是where可以使用rushmore技术，而having就不能，在速度上后者要慢如果要涉及到计算的字 段，就表示在没计算之前，这个字段的值是不确定的，根据上篇写的工作流程，where的作用时间是在计算之前就完成的，而having就是在计算后才起作 用的，所以在这种情况下，两者的结果会不同。在多表联接查询时，on比where更早起作用。系统首先根据各个表之间的联接条件，把多个表合成一个临时表 后，再由where进行过滤，然后再计算，计算完后再由having进行过滤。由此可见，要想过滤条件起到正确的作用，首先要明白这个条件应该在什么时候起作用，然后再决定放在那里。
（12） 减少对表的查询：
在含有子查询的SQL语句中,要特别注意减少对表的查询.例子：
select TAB_NAME from tables where (TAB_NAME,DB_VER) = ( select TAB_NAME,DB_VER from TAB_COLUMNS where VERSION = 604)
（13） 通过内部函数提高SQL效率：
复杂的SQL往往牺牲了执行效率. 能够掌握上面的运用函数解决问题的方法在实际工作中是非常有意义的。
（14） 使用表的别名(Alias)：
当在SQL语句中连接多个表时, 请使用表的别名并把别名前缀于每个Column上.这样一来,就可以减少解析的时间并减少那些由Column歧义引起的语法错误。
（15） 用exists替代in、用notexists替代not in：
在许多基于基础表的查询中,为了满足一个条件,往往需要对另一个表进行联接.在这种情况下, 使用exists(或notexists)通常将提高查询的效率. 在子查询中,not in子句将执行一个内部的排序和合并. 无论在哪种情况下,not in都是最低效的 (因为它对子查询中的表执行了一个全表遍历). 为了避免使用notin,我们可以把它改写成外连接(Outer Joins)或notexists。
例子：
（高效）select * from emp (基础表) where empno > 0 and exists (select 'X' from dept where dept.deptno = emp.deptno and loc = 'MELB')
(低效)select * from emp (基础表) where empno > 0 and deptno in(select deptno from dept where loc = 'MELB')
（16） 识别'低效执行'的SQL语句：
虽然目前各种关于SQL优化的图形化工具层出不穷,但是写出自己的SQL工具来解决问题始终是一个最好的方法：
select EXECUTIONS , DisK_READS, BUFFER_GETS,
ROUND((BUFFER_GETS-DisK_READS)/BUFFER_GETS,2) Hit_radio,
ROUND(DisK_READS/EXECUTIONS,2) Reads_per_run,
SQL_TEXT
from V$SQLAREA
where EXECUTIONS>0
and BUFFER_GETS > 0
and (BUFFER_GETS-DisK_READS)/BUFFER_GETS < 0.8
order by 4 DESC;
（17） 用索引提高效率：
索引是表的一个概念部分,用来提高检索数据的效率，Oracle使用了一个复杂的自平衡B-tree结构. 通常,通过索引查询数据比全表扫描要快. 当Oracle找出执行查询和Update语句的最佳路径时, Oracle优化器将使用索引. 同样在联结多个表时使用索引也可以提高效率. 另一个使用索引的好处是,它提供了主键(primary key)的唯一性验证.。那些LONG或LONG RAW数据类型, 你可以索引几乎所有的列. 通常, 在大型表中使用索引特别有效. 当然,你也会发现, 在扫描小表时,使用索引同样能提高效率. 虽然使用索引能得到查询效率的提高,但是我们也必须注意到它的代价. 索引需要空间来存储,也需要定期维护, 每当有记录在表中增减或索引列被修改时, 索引本身也会被修改. 这意味着每条记录的inSERT , delete , UPDATE将为此多付出4 , 5 次的磁盘I/O . 因为索引需要额外的存储空间和处理,那些不必要的索引反而会使查询反应时间变慢.。定期的重构索引是有必要的：
alter index REBUILD
（18） 用exists替换distinct：
当提交一个包含一对多表信息(比如部门表和雇员表)的查询时,避免在select子句中使用distinct. 一般可以考虑用EXisT替换,exists 使查询更为迅速,因为RDBMS核心模块将在子查询的条件一旦满足后,立刻返回结果. 例子：
(低效):
select distinct deptno,dname from dept D , emp E where D.deptno = E.deptno
(高效):
select deptno,dname from dept D where exists ( select 'X' from emp E where E.deptno = D.deptno);
（19） sql语句用大写的；因为oracle总是先解析sql语句，把小写的字母转换成大写的再执行。
（20） 在java代码中尽量少用连接符'＋'连接字符串！
（21） 避免在索引列上使用not，通常我们要避免在索引列上使用not, not会产生在和在索引列上使用函数相同的影响. 当Oracle'遇到'not,他就会停止使用索引转而执行全表扫描。
（22） 避免在索引列上使用计算
where子句中，如果索引列是函数的一部分．优化器将不使用索引而使用全表扫描．举例:
低效：
select … from dept where sal * 12 > 25000;
高效:
select … from dept where sal > 25000/12;
（23） 用>=替代>
高效:
select * from emp where deptno >=4
低效:
select * from emp where deptno >3
两者的区别在于, 前者DBMS将直接跳到第一个dept等于4的记录而后者将首先定位到deptno=3的记录并且向前扫描到第一个dept大于3的记录。
（24） 用union替换or (适用于索引列)
通常情况下, 用union替换where子句中的or将会起到较好的效果. 对索引列使用or将造成全表扫描. 注意, 以上规则只针对多个索引列有效. 如果有column没有被索引, 查询效率可能会因为你没有选择or而降低. 在下面的例子中, locid 和region上都建有索引.
高效:
select locid , loc_desc , region
from location
where locid = 10
union
select locid , loc_desc , region
from location
where region = 'MELBOURNE'
低效:
select locid , loc_desc , region
from location
where locid = 10 or region = 'MELBOURNE'
如果你坚持要用or, 那就需要返回记录最少的索引列写在最前面.
（25） 用in来替换or
这是一条简单易记的规则，但是实际的执行效果还须检验，在Oracle8i下，两者的执行路径似乎是相同的．
低效:
select…. from location where locid = 10 or locid = 20 or locid = 30
高效
select… from location where loc_id in(10,20,30);
（26） 避免在索引列上使用is null和is not null
避免在索引中使用任何可以为空的列，Oracle将无法使用该索引．对于单列索引，如果列包含空值，索引中将不存在此记录. 对于复合索引，如果每个列都为空，索引中同样不存在此记录. 如果至少有一个列不为空，则记录存在于索引中．举例: 如果唯一性索引建立在表的A列和B列上, 并且表中存在一条记录的A,B值为(123,null) , Oracle将不接受下一条具有相同A,B值（123,null）的记录(插入). 然而如果所有的索引列都为空，Oracle将认为整个键值为空而空不等于空. 因此你可以插入1000 条具有相同键值的记录,当然它们都是空! 因为空值不存在于索引列中,所以where子句中对索引列进行空值比较将使Oracle停用该索引.
低效: (索引失效)
select … from department where dcode is not null;
高效: (索引有效)
select … from department where dcode >=0;
（27） 总是使用索引的第一个列：
如果索引是建立在多个列上, 只有在它的第一个列(leading column)被where子句引用时,优化器才会选择使用该索引. 这也是一条简单而重要的规则，当仅引用索引的第二个列时,优化器使用了全表扫描而忽略了索引。
（28） 用union all 替换union ( 如果有可能的话)：
当SQL 语句需要union两个查询结果集合时,这两个结果集合会以union all的方式被合并, 然后在输出最终结果前进行排序. 如果用union all替代union, 这样排序就不是必要了. 效率就会因此得到提高. 需要注意的是，union all 将重复输出两个结果集合中相同记录. 因此各位还是要从业务需求分析使用union all的可行性. union 将对结果集合排序,这个操作会使用到SorT_AREA_SIZE这块内存. 对于这块内存的优化也是相当重要的. 下面的SQL可以用来查询排序的消耗量
低效：
select ACCT_NUM, BALANCE_AMT
from DEBIT_TRANSACTIONS
where TRAN_DATE = '31-DEC-95'
union
select ACCT_NUM, BALANCE_AMT
from DEBIT_TRANSACTIONS
where TRAN_DATE = '31-DEC-95'
高效:
select ACCT_NUM, BALANCE_AMT
from DEBIT_TRANSACTIONS
where TRAN_DATE = '31-DEC-95'
union all
select ACCT_NUM, BALANCE_AMT
from DEBIT_TRANSACTIONS
where TRAN_DATE = '31-DEC-95'
（29） 用where替代order by：
order by 子句只在两种严格的条件下使用索引.
order by中所有的列必须包含在相同的索引中并保持在索引中的排列顺序.
order by中所有的列必须定义为非空.
where子句使用的索引和order by子句中所使用的索引不能并列.
例如:
表dept包含以下列:
dcode PK not null
dept_DESC not null
dept_TYPE null
低效: (索引不被使用)
select dcode from dept order by dept_TYPE
高效: (使用索引)
select dcode from dept where dept_TYPE > 0
（30） 避免改变索引列的类型:
当比较不同数据类型的数据时, Oracle自动对列进行简单的类型转换.
假设 empno是一个数值类型的索引列.
select … from emp where empno = '123'
实际上,经过Oracle类型转换, 语句转化为:
select … from emp where empno = TO_NUMBER('123')
幸运的是,类型转换没有发生在索引列上,索引的用途没有被改变.
现在,假设emp_TYPE是一个字符类型的索引列.
select … from emp where emp_TYPE = 123
这个语句被Oracle转换为:
select … from emp where TO_NUMBER(emp_TYPE)=123
因为内部发生的类型转换, 这个索引将不会被用到! 为了避免Oracle对你的SQL进行隐式的类型转换, 最好把类型转换用显式表现出来. 注意当字符和数值比较时, Oracle会优先转换数值类型到字符类型。
分析select emp_name form employee where salary > 3000 在此语句中若salary是Float类型的，则优化器对其进行优化为Convert(float,3000)，因为3000是个整数，我们应在编程时使用3000.0而不要等运行时让DBMS进行转化。同样字符和整型数据的转换。
（31） 需要当心的where子句:
某些select 语句中的where子句不使用索引. 这里有一些例子.
在下面的例子里, (1)'!=' 将不使用索引. 记住, 索引只能告诉你什么存在于表中, 而不能告诉你什么不存在于表中. (2) ' | |'是字符连接函数. 就象其他函数那样, 停用了索引. (3) '+'是数学函数. 就象其他数学函数那样, 停用了索引. (4)相同的索引列不能互相比较,这将会启用全表扫描.
（32） a. 如果检索数据量超过30%的表中记录数.使用索引将没有显著的效率提高. b. 在特定情况下, 使用索引也许会比全表扫描慢, 但这是同一个数量级上的区别. 而通常情况下,使用索引比全表扫描要块几倍乃至几千倍!
（33） 避免使用耗费资源的操作：
带有distinct,union,minus,intersect,order by的SQL语句会启动SQL引擎执行耗费资源的排序(SorT)功能. distinct需要一次排序操作, 而其他的至少需要执行两次排序. 通常, 带有union, minus , intersect的SQL语句都可以用其他方式重写. 如果你的数据库的SorT_AREA_SIZE调配得好, 使用union , minus, intersect也是可以考虑的, 毕竟它们的可读性很强。
（34） 优化group by：
提高group by 语句的效率, 可以通过将不需要的记录在group by 之前过滤掉.下面两个查询返回相同结果但第二个明显就快了许多.
低效:
select job , avg(sal)
from emp
group by job
having job = 'PRESIDENT'
or job = 'MANAGER'
高效:
select job , avg(sal)
from emp
where job = 'PRESIDENT'
or job = 'MANAGER'
group by job　　
一、操作符优化：
1、in 操作符
　　用in写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。但是用in的SQL性能总是比较低的，从Oracle执行的步骤来分析用in的SQL与不用in的SQL有以下区别：
　　Oracle试图将其转换成多个表的连接，如果转换不成功则先执行in里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。由此可见用in的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。在业务密集的SQL当中尽量不采用in操作符。
　　优化sql时，经常碰到使用in的语句，一定要用exists把它给换掉，因为Oracle在处理In时是按Or的方式做的，即使使用了索引也会很慢。
2、 not in操作符
　　强列推荐不使用的，因为它不能应用表的索引。用notexists 或（外连接+判断为空）方案代替
　　比如：
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select col1,col2,col3 from table1 a where a.col1 notin(select col1 from table2)
　　可替换为：
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select col1,col2,col3 from table1 a where not exists 　　(select 'x' from table2 b where a.col1=b.col1)
　　a$amp;
　　a$amp;
3、is null 或is not null操作（判断字段是否为空）
　　判断字段是否为空一般是不会应用索引的，因为B树索引是不索引空值的。
　　用其它相同功能的操作运算代替，
　　a is not null 改为 a>0 或a>''等。
　　不允许字段为空，而用一个缺省值代替空值，如业扩申请中状态字段不允许为空，缺省为申请。
　　建立位图索引（有分区的表不能建，位图索引比较难控制，如字段值太多索引会使性能下降，多人更新操作会增加数据块锁的现象）。
　　避免在索引列上使用is null 和is not null 避免在索引中使用任何可以为空的列，Oracle 将无法使用该索引．对于单列索引，如果列包含空值，索引中将不存在此记录. 对于复合索引，如果每个列都为空，索引中同样不存在 此记录. 如果至少有一个列不为空，则记录存在于索引中．举例: 如果唯一性索引建立在表的A 列和B 列上, 并且表中存在一条记录的A,B 值为(123,null) ,Oracle将不接受下一 条具有相同A,B 值（123,null）的记录(插入). 然而如果所有的索引列都为空，Oracle 将认为整个键值为空而空不等于空. 因此你可以插入1000 条具有相同键值的记录,当然它们都是空! 因为空值不存在于索引列中,所以where 子句中对索引列进行空值比较将使Oracle 停用该索引.
　　低效: (索引失效)
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select … from department where dcode is not null;
　　高效: (索引有效)
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select … from department where dcode >=0;
4、> 及 < 操作符（大于或小于操作符）
　　大于或小于操作符一般情况下是不用调整的，因为它有索引就会采用索引查找，但有的情况下可以对它进行优化，如一个表有100万记录，一个数值型字段 A，30万记录的A=0，30万记录的A=1，39万记录的A=2，1万记录的A=3。那么执行A>2与A>=3的效果就有很大的区别了，因为A>2时Oracle会先找出为2的记录索引再进行比较，而A>=3时Oracle则直接找到=3的记录索引。
用>=替代>
高效:
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select … from department where dcode >=0;
　　低效:
　　两者的区别在于, 前者DBMS 将直接跳到第一个dept等于4的记录而后者将首先定位到dept NO=3的记录并且向前扫描到第一个dept 大于3的记录.
5、LIKE操作符
LIKE操作符可以应用通配符查询，里面的通配符组合可能达到几乎是任意的查询，但是如果用得不好则会产生性能上的问题，如LIKE '%5400%' 这种查询不会引用索引，而LIKE'X5400%'则会引用范围索引。一个实际例子：用YW_YHJBQK表中营业编号后面的户标识号可来查询营业编号 YY_BH LIKE'%5400%' 这个条件会产生全表扫描，如果改成YY_BHlike'X5400%' or YY_BHlike'B5400%'
则会利用YY_BH的索引进行两个范围的查询，性能肯定大大提高。
6、用exists 替换distinct：
当提交一个包含一对多表信息(比如部门表和雇员表)的查询时,避免在select 子句中使用distinct. 一般可以考虑用EXisT 替换,exists 使查询更为迅速,因为RDBMS 核心模块将在子查询的条件一旦满足后,立刻返回结果.
例子：
(低效):
　　(高效):
　　如：
用exists 替代in、用notexists 替代not in：
在许多基于基础表的查询中,为了满足一个条件,往往需要对另一个表进行联接.在这种情况下, 使用exists(或notexists)通常将提高查询的效率. 在子查询中,notin子句将执行一个内部的排序和合并. 无论在哪种情况下,not in都是最低效的(因为它对子查询中的表执行了一个全表遍历). 为了避免使用notin,我们可以把它改写成外连接(Outer Joins)或notexists.
例子：
(高效):
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select * from emp (基础表) where empno > 0 andexists 　　(select 'X' from dept where dept.deptno = emp.deptno and loc='MELB')
　　(低效):
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select * from emp (基础表) where empno > 0 and deptnoin　　(select DEP TNO from dept where loc ='MELB')
7、用union 替换or (适用于索引列)
通常情况下, 用union 替换where 子句中的or 将会起到较好的效果. 对索引列使用or 将造成全表扫描. 注意, 以上规则只针对多个索引列有效. 如果有column 没有被索引, 查询效率可能会因为你没有选择or 而降低. 在下面的例子中, locid 和region 上都建有索引.
(高效):
　　(低效):
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select locid,loc_desc,region from location where locid= 10 or region = 'MELBOURNE'

如果你坚持要用or, 那就需要返回记录最少的索引列写在最前面.
8、用in 来替换or
这是一条简单易记的规则，但是实际的执行效果还须检验，在Oracle8i 下，两者的执行路径似乎是相同的．
低效:
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) from location where locid = 10 or locid = 20 or locid = 30
高效:
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select… from location where loc_inin(10,20,30);
二、SQL语句结构优化
1、选择最有效率的表名顺序(只在基于规则的优化器中有效)：
Oracle 的解析器按照从右到左的顺序处理from子句中的表名，from 子句中写在最后的表(基础表driving table)将被最先处理，在from 子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表.
2、where 子句中的连接顺序：
Oracle 采用自下而上的顺序解析where 子句,根据这个原理,表之间的连接必须写在其他where 条件之前, 那些可以过滤掉最大数量记录的条件必须写在where 子句的末尾.
3、select 子句中避免使用' * '：
Oracle 在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间
4、减少访问数据库的次数：
Oracle 在内部执行了许多工作: 解析SQL 语句, 估算索引的利用率, 绑定变量, 读数据块等；
5、在SQL*Plus , SQL*Forms 和Pro*C 中重新设置ARRAYSIZE 参数, 可以增加每次数据库访问的检索数据量,建议值为200
6、使用DECODE 函数来减少处理时间：使用DECODE 函数可以避免重复扫描相同记录或重复连接相同的表.
7、 整合简单,无关联的数据库访问： 如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使它们之间没有关系)
8、删除重复记录：
最高效的删除重复记录方法( 因为使用了ROWID)例子：
9、用truncate 替代delete删除全表记录：
当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) 用来存放可以被恢复的信息. 如果你没有commit 事务,Oracle 会将数据恢复到删除之前的状态(准确地说是恢复到执行删除命令之前的状况) 而当运用truncate 时, 回滚段不再存放任何可被恢复的信息.
当命令运行后,数据不能被恢复.因此很少的资源被调用,执行时间也会很短. (译者按: truncate 只在删除全表适用,truncate是DDL 不是DML)
10、尽量多使用commit：
只要有可能,在程序中尽量多使用commit, 这样程序的性能得到提高,需求也会因为commit所释放的资源而减少:
commit 所释放的资源: a. 回滚段上用于恢复数据的信息. b. 被程序语句获得的锁 ，c. redo log buffer 中的空间 ；d.Oracle为管理上述3种资源中的内部花费
11、用where 子句替换having 子句：
避免使用having 子句, having 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序,总计等操作. 如果能通过where 子句限制记录的数目,那就能减少这方面的开销. (非oracle中)on、where、having 这三个都可以加条件的子句中，on 是最先执行，where 次之，having 最后，因为on是先把不符合条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的， where 也应该比having 快点的，因为它过滤数据后才进行sum，在两个表联接时才用on 的，所以在一个表的时候，就剩下where跟having比较了。在这单表查询统计的情况下，如果要过滤的条件没有涉及到要计算字段，那它们的结果是一样的，只是where 可以使用rushmore技术，而having 就不能，在速度上后者要慢如果要涉及到计算的字段，就表示在没计算之前，这个字段的值是不确定的，根据上篇写的工作流程，where 的作用时间是在计算之前就完成的，而having 就是在计算后才起作用的，所以在这种情况下，两者的结果会不同。在多表联接查询时， on 比where 更早起作用。系统首先根据各个表之间的联接条件，把多个表合成一个临时表后，再由where进行过滤，然后再计算，计算完后再由having进行过滤。由此可见，要想过滤条件起到正确的作用，首先要明白这个条件应该在什么时候起作用，然后再决定放在那里
12、减少对表的查询：
在含有子查询的SQL 语句中,要特别注意减少对表的查询.例子：
13、通过内部函数提高SQL 效率.：
复杂的SQL 往往牺牲了执行效率. 能够掌握上面的运用函数解决问题的方法在实际工作中是非常有意义的
14、使用表的别名(Alias)：
当在SQL 语句中连接多个表时, 请使用表的别名并把别名前缀于每个Column 上.这样一来, 就可以减少解析的时间并减少那些由Column 歧义引起的语法错误.
15、识别'低效执行'的SQL 语句：
虽然目前各种关于SQL 优化的图形化工具层出不穷,但是写出自己的SQL 工具来解决问题始终是一个最好的方法：
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select EXECUTIONS,DisK_READS,BUFFER_GETS, 2 ROUND((BUFFER_GETS-DisK_READS)/BUFFER_GETS,2) Hit_radio, 3 ROUND(DisK_READS/EXECUTIONS,2) Reads_per_run, SQL_TEXT 4 from V$SQLAREA where EXECUTIONS>0 and BUFFER_GETS > 0 5 and(BUFFER_GETS-DisK_READS)/BUFFER_GETS < 0.8 6 order by 4 DESC;
16、用索引提高效率：
索引是表的一个概念部分,用来提高检索数据的效率，Oracle 使用了一个复杂的自平衡B-tree 结构. 通常,通过索引查询数据比全表扫描要快. 当Oracle 找出执行查询和Update 语句的最佳路径时,Oracle优化器将使用索引. 同样在联结多个表时使用索引也可以提高效率. 另一个使用索引的好处是,它提供了主键(primary key)的唯一性验证.。那些LONG 或LONGRAW 数据类型, 你可以索引几乎所有的列. 通常, 在大型表中使用索引特别有效. 当然, 你也会发现, 在扫描小表时,使用索引同样能提高效率. 虽然使用索引能得到查询效率的提高,但是我们也必须注意到它的代价. 索引需要空间来存储,也需要定期维护, 每当有记录在表中增减或索引列被修改时, 索引本身也会被修改. 这意味着每条记录的inSERT , delete , UPDATE 将为此多付出4 , 5次的磁盘I/O . 因为索引需要额外的存储空间和处理, 那些不必要的索引反而会使查询反应时间变慢.。定期的重构索引是有必要的.：
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 alter index <indexNAME> REBUILD <tablesPACENAME>
17、sql 语句用大写的；因为oracle 总是先解析sql 语句，把小写的字母转换成大写的再执行。
18、在java 代码中尽量少用连接符'＋'连接字符串！
19、避免在索引列上使用not 通常， 我们要避免在索引列上使用not, not 会产生在和在索引列上使用函数相同的影响. 当Oracle'遇到'not,他就会停止使用索引转而执行全表扫描.
20、避免在索引列上使用计算．
where 子句中，如果索引列是函数的一部分．优化器将不使用索引而使用全表扫描．
举例:
低效：
<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select … from dept where sal * 12 > 25000;
高效:
21、总是使用索引的第一个列：
如果索引是建立在多个列上, 只有在它的第一个列(leading column)被where 子句引用时, 优化器才会选择使用该索引. 这也是一条简单而重要的规则，当仅引用索引的第二个列时, 优化器使用了全表扫描而忽略了索引
22、用union all 替换union ( 如果有可能的话)：
当SQL 语句需要union 两个查询结果集合时,这两个结果集合会以union all 的方式被合并, 然后在输出最终结果前进行排序. 如果用union all 替代union, 这样排序就不是必要了. 效率就会因此得到提高. 需要注意的是，union all 将重复输出两个结果集合中相同记录. 因此各位还是要从业务需求分析使用union all 的可行性. union 将对结果集合排序, 这个操作会使用到SorT_AREA_SIZE 这块内存. 对于这块内存的优化也是相当重要的. 下面的SQL 可以用来查询排序的消耗量
低效：
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select ACCT_NUM,BALANCE_AMT from DEBIT_TRANSACTIONS where TRAN_DATE = '31-DEC-95' 2 union 3 select ACCT_NUM,BALANCE_AMT from DEBIT_TRANSACTIONS where TRAN_DATE = '31-DEC-95'
高效:
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select ACCT_NUM,BALANCE_AMT from DEBIT_TRANSACTIONS where TRAN_DATE = '31-DEC-95' 2 union all 3 select ACCT_NUM,BALANCE_AMT from DEBIT_TRANSACTIONS where TRAN_DATE = '31-DEC-95'
23、用where 替代order by：
order by 子句只在两种严格的条件下使用索引. order by 中所有的列必须包含在相同的索引中并保持在索引中的排列顺序. order by 中所有的列必须定义为非空. where 子句使用的索引和order by 子句中所使用的索引不能并列.
例如:
表dept 包含以下列:
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 dcode PK not null 2 dept_DESC not null 3 dept_TYPE null
低效: (索引不被使用)
　　高效: (使用索引)
24、避免改变索引列的类型.:
当比较不同数据类型的数据时,Oracle自动对列进行简单的类型转换. 假设empno 是一个数值类型的索引列. select … from emp where empno = '123' 实际上,经过Oracle 类型转换, 语句转化为:
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select … from emp where empno = TO_NUMBER('123')
幸运的是,类型转换没有发生在索引列上,索引的用途没有被改变. 现在,假设emp_TYPE 是一个字符类型的索引列.
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select … from emp where emp_TYPE = 123
这个语句被Oracle 转换为:
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select … from emp whereTO_NUMBER(emp_TYPE)=123
因为内部发生的类型转换, 这个索引将不会被用到! 为了避免Oracle 对你的SQL 进行隐式 的类型转换, 最好把类型转换用显式表现出来. 注意当字符和数值比较时,Oracle会优先 转换数值类型到字符类型
25、需要当心的where 子句:
某些select 语句中的where 子句不使用索引. 这里有一些例子. 在下面的例子里, (1)'!=' 将不使用索引. 记住, 索引只能告诉你什么存在于表中, 而不能告诉你什么不存在于表中. (2) '||'是字符连接函数. 就象其他函数那样, 停用了索引. (3) '+'是数学函数. 就象其他数学函数那样, 停用了索引. (4)相同的索引列不能互相比较,这将会启用全表扫描.
26、a. 如果检索数据量超过30%的表中记录数.使用索引将没有显著的效率提高. b. 在特定情况下, 使用索引也许会比全表扫描慢, 但这是同一个数量级上的区别. 而通常情况下,使用索引比全表扫描要块几倍乃至几千倍!
27、避免使用耗费资源的操作:带有
　　的SQL 语句会启动SQL 引擎执行耗费资源的排序(SorT)功能. distinct 需要一次排序操作, 而其他的至少需要执行两次排序. 通常, 带有union, minus , intersect 的SQL 语句都可以用其他方式重写. 如果你的数据库的SorT_AREA_SIZE 调配得好, 使用union , minus, intersect 也是可以考虑的, 毕竟它们的可读性很强
28、优化group by:
提高group by 语句的效率, 可以通过将不需要的记录在group by 之前过滤掉.下面两个
查询返回相同结果但第二个明显就快了许多.
低效:
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select job,avg(sal)from emp group by job having job= 'PRESIDENT' or job = 'MANAGER'
高效:
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select job,avg(sal)from emp where job = 'PRESIDENT' or job='MANAGER' group by job
　　Oracle优化器（Optimizer）是Oracle在执行SQL之前分析语句的工具。
Oracle的优化器有两种优化方式：基于规则的（RBO）和基于代价的（CBO）。
RBO：优化器遵循Oracle内部预定的规则。
CBO：依据语句执行的代价，主要指对CPU和内存的占用。优化器在判断是否使用CBO时，要参照表和索引的统计信息。统计信息要在对表做analyze后才会有。Oracle8及以后版本，推荐用CBO方式。
Oracle优化器的优化模式主要有四种：
Rule：基于规则；
Choose：默认模式。根据表或索引的统计信息，如果有统计信息，则使用CBO方式；如果没有统计信息，相应列有索引，则使用RBO方式。
First rows：与Choose类似。不同的是如果表有统计信息，它将以最快的方式返回查询的前几行，以获得最佳响应时间。
All rows：即完全基于Cost的模式。当一个表有统计信息时，以最快方式返回表所有行，以获得最大吞吐量。没有统计信息则使用RBO方式。
设定优化模式的方式
Instance级别：
　　Session级别：
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 SQL> alter SESSION SET OPTIMIZER_MODE=;----来设定。
语句级别：通过SQL> select /*+all+_ROWS*/ ……;来设定。可用的HINT包括/*+all_ROWS*/、/*+FIRST_ROWS*/、/*+CHOOSE*/、/*+RULE*/ 等。
要注意的是，如果表有统计信息，则可能造成语句不走索引的结果。可以用SQL>ANALYZE TABLE table_name delete STATisTICS; 删除索引。
对列和索引更新统计信息的SQL：
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 SQL> ANALYZE TABLE table_name COMPUTE STATisTICS; 2 SQL> ANALYZE index index_name ESTIMATE STATisTICS;
Oracle优化器
Sql优化工具的介绍：
--Autotrace使用方法：
sqlexpert；toad；explain-table；PL/SQL；OEM等
掌握一种，熟练使用即可。
看执行计划用sqlplus 的autotrace，优化用sql expert。
1. DBA在db中创建plustrace 角色：运行
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 @ /sqlplus/admin/plustrce.sql
2. DBA给用户赋予角色：
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 grant plustrace to username;
3. 用户创建自己的plan_table：运行
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 @ /rdbms/admin/utlxplan.sql。----以上是第一次使用时需要进行的必要操作。
4. 用户sqlplus连接数据库，对会话进行如下设置：
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 Set autotrace -----off/on/trace[only]------explain/statistics，
然后录入sql语句回车即可查看执行计划—推荐；
或者用如下命令行：
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 Explain plan set statement_id='myplan1' for Your sql-statement;
　　然后查看用户自己的plan_table
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 ----在init<SID>.ora文件中设定OPTIMIZER_MODE；
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;distinct,union,minus,intersect,order by
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select dcode from dept where dept_TYPE > 0
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select dcode from dept order by dept_TYPE
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select … from dept where sal > 25000/12;
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select TAB_NAME from tables where (TAB_NAME,DB_VER) = 　　(select TAB_NAME,DB_VER from TAB_COLUMNS where VERSION = 604)
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 delete from emp E where E.ROWID > 　　(select min(X.ROWID) from emp X where X.empno = E.empno);
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select locid,loc_desc,region from location where locid = 10 　　union select locid , loc_desc , region from location where region = 'MELBOURNE'
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select deptno,dname from dept D whereexists 　　(select 'X' from emp E where E.deptno = D.deptno);
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select distinct deptno,dname from dept D , emp E where D.deptno = E.deptno
　　<!-- Code highlighting produced by Actipro CodeHighlighter (freeware) ;1 select * from emp where deptno