Oracle SQL的优化

SQL的优化应该从 5 个方面进行调整：
1.去掉不必要的大型表的全表扫描
2.缓存小型表的全表扫描
3.检验优化索引的使用
4.检验优化的连接技术
5.尽可能减少执行计划的 Cost

SQL语句：
是对数据库( 数据 ) 进行操作的惟一途径；
消耗了70%~90% 的数据库资源；独立于程序设计逻辑，相对于对程序源代码的优化，对 SQL 语句的优化在时间成本和风险上的代价都很低；
可以有不同的写法；易学，难精通。

SQL优化：
固定的SQL 书写习惯，相同的查询尽量保持相同，存储过程的效率较高。
应该编写与其格式一致的语句，包括字母的大小写、标点符号、换行的位置等都要一致

ORACLE优化器：
在任何可能的时候都会对表达式进行评估，并且把特定的语法结构转换成等价的结构，这么做的原因是
要么结果表达式能够比源表达式具有更快的速度
要么源表达式只是结果表达式的一个等价语义结构
不同的SQL 结构有时具有同样的操作（例如： =ANY(subquery)andIN(subquery) ）， ORACLE 会把他们映射到一个单一的语义结构。
1常量优化：
常量的计算是在语句被优化时一次性完成，而不是在每次执行时。下面是检索月薪大于2000 的的表达式：
sal>24000/12
sal>2000
sal*12>24000
如果SQL 语句包括第一种情况，优化器会简单地把它转变成第二种。
优化器不会简化跨越比较符的表达式，例如第三条语句，鉴于此，应尽量写用常量跟字段比较检索的表达式，而不要将字段置于表达式当中。否则没有办法优化，比如如果sal 上有索引，第一和第二就可以使用，第三就难以使用。

2操作符优化：
优化器把使用LIKE 操作符和一个没有通配符的表达式组成的检索表达式转换为一个 “ = ” 操作符表达式。
例如：优化器会把表达式enameLIKE'SMITH' 转换为 ename='SMITH'
优化器只能转换涉及到可变长数据类型的表达式，前一个例子中，如果ENAME 字段的类型是 CHAR(10) ，那么优化器将不做任何转换。

一般来讲LIKE 比较难以优化。
其中：
~~ IN操作符优化：
优化器把使用IN 比较符的检索表达式替换为等价的使用 “ = ” 和 “ OR ” 操作符的检索表达式。
例如，优化器会把表达式enameIN('SMITH','KING','JONES') 替换为
ename='SMITH'ORename='KING'ORename='JONES‘

oracle 会将 in 后面的东西生成一张内存中的临时表。然后进行查询。

如何编写高效的SQL:
当然要考虑sql 常量的优化和操作符的优化啦，另外，还需要：
1合理的索引设计：
例：表record 有 620000 行，试看在不同的索引下，下面几个 SQL 的运行情况：
语句A
SELECTcount(*)FROMrecord
WHEREdate>'19991201'anddate<'19991214‘ andamount>2000
语句B
SELECTcount(*)FROMrecord
WHEREdate>'19990901'andplaceIN('BJ','SH')
语句C
SELECTdate,sum(amount)FROMrecord
groupbydate
1在 date 上建有一个非聚集索引
A： (25 秒 )
B： (27 秒 )
C： (55 秒 )
分析：
date上有大量的重复值，在非聚集索引下，数据在物理上随机存放在数据页上，在范围查找时，必须执行一次表扫描才能找到这一范围内的全部行。
2在 date 上的一个聚集索引
A：（ 14 秒）
B：（ 14 秒）
C：（ 28 秒）
分析：
在聚集索引下，数据在物理上按顺序在数据页上，重复值也排列在一起，因而在范围查找时，可以先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提高了查询速度。
3在 place ， date ， amount 上的组合索引
A：（ 26 秒）
C：（ 27 秒）
B：（ <1 秒）
分析：
这是一个不很合理的组合索引，因为它的前导列是place ，第一和第二条 SQL 没有引用 place ，因此也没有利用上索引；第三个 SQL 使用了 place ，且引用的所有列都包含在组合索引中，形成了索引覆盖，所以它的速度是非常快的。
4在 date ， place ， amount 上的组合索引
A： (<1 秒 )
B：（ <1 秒）
C：（ 11 秒）
分析：
这是一个合理的组合索引。它将date 作为前导列，使每个 SQL 都可以利用索引，并且在第一和第三个 SQL 中形成了索引覆盖，因而性能达到了最优。

总结1
缺省情况下建立的索引是非聚集索引，但有时它并不是最佳的；合理的索引设计要建立在对各种查询的分析和预测上。一般来说：
有大量重复值、且经常有范围查询（between,>,< ， >=,<= ）和 orderby 、 groupby 发生的列，考虑建立聚集索引；
经常同时存取多列，且每列都含有重复值可考虑建立组合索引；在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“ 性别 ” 列上只有 “ 男 ” 与 “ 女 ” 两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。
组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。
2避免使用不兼容的数据类型：
例如float 和 INt 、 char 和 varchar 、 bINary 和 varbINary 是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如 :
SELECTnameFROMemployeeWHEREsalary＞ 60000
在这条语句中, 如 salary 字段是 money 型的 , 则优化器很难对其进行优化 , 因为 60000 是个整型数。我们应当在编程时将整型转化成为钱币型 , 而不要等到运行时转化。
3ISNULL与 ISNOTNULL ：
不能用null 作索引，任何包含 null 值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有 null ，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。任何在 WHERE 子句中使用 isnull 或 isnotnull 的语句优化器是不允许使用索引的。
5IN、 OR 子句常会使用工作表，使索引失效：
如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。
6避免或简化排序：
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：
索引中不包括一个或几个待排序的列；
groupby或 orderby 子句中列的次序与索引的次序不一样；
排序的列来自不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。

7消除对大型表行数据的顺序存取：
在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3 层的查询，如果每层都查询 1000 行，那么这个查询就要查询 10 亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄 ?? ）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在 “ 学号 ” 这个连接字段上建立索引。
还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的WHERE 子句强迫优化器使用顺序存取。下面的查询将强迫对 orders 表执行顺序操作：
SELECT＊ FROMordersWHERE(customer_num=104ANDorder_num>1001)ORorder_num=1008
虽然在customer_num 和 order_num 上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：
SELECT＊ FROMordersWHEREcustomer_num=104ANDorder_num>1001
UNION
SELECT＊ FROMordersWHEREorder_num=1008
这样就能利用索引路径处理查询。

8避免相关子查询：
一个列的标签同时在主查询和WHERE 子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。
9避免困难的正规表达式：
MATCHES和 LIKE 关键字支持通配符匹配，技术上叫正规表达式 。但这种匹配特别耗费时间。

例如：SELECT ＊ FROMcustomerWHEREzipcodeLIKE “ 98___ ”
即使在zipcode 字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为 SELECT ＊ FROMcustomerWHEREzipcode> “ 98000 ” ，在执行查询时就会利用索引来查询，显然会大大提高速度。
另外，还要避免非开始的子串。例如语句：SELECT ＊ FROMcustomerWHEREzipcode[2 ， 3]> “ 80 ” ，在 WHERE 子句中采用了非开始子串，因而这个语句也不会使用索引。

10不充份的连接条件：
例：表card 有 7896 行，在 card_no 上有一个非聚集索引，表 account 有 191122 行，在 account_no 上有一个非聚集索引，试看在不同的表连接条件下，两个 SQL 的执行情况：
SELECTsum(a.amount)FROMaccounta,cardbWHEREa.card_no=b.card_no
（20 秒）
将SQL 改为：
SELECTsum(a.amount)FROMaccounta,cardbWHEREa.card_no=b.card_noanda.account_no=b.account_no
（<1 秒）
分析：
在第一个连接条件下，最佳查询方案是将account 作外层表， card 作内层表，利用 card 上的索引，其 I/O 次数可由以下公式估算为：
外层表account 上的 22541 页 + （外层表 account 的 191122 行 * 内层表 card 上对应外层表第一行所要查找的 3 页） =595907 次 I/O
在第二个连接条件下，最佳查询方案是将card 作外层表， account 作内层表，利用 account 上的索引，其 I/O 次数可由以下公式估算为：
外层表card 上的 1944 页 + （外层表 card 的 7896 行 * 内层表 account 上对应外层表每一行所要查找的 4 页） =33528 次 I/O
可见，只有充份的连接条件，真正的最佳方案才会被执行。
多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数* 内层表中每一次查找的次数确定，乘积最小为最佳方案。
不可优化的WHERE 子句
例1
下列SQL 条件语句中的列都建有恰当的索引，但执行速度却非常慢：
SELECT*FROMrecordWHEREsubstrINg(card_no,1,4)='5378'
(13秒 )
SELECT*FROMrecordWHEREamount/30<1000
（11 秒）
SELECT*FROMrecordWHEREconvert(char(10),date,112)='19991201'
（10 秒）
分析：
WHERE子句中对列的任何操作结果都是在 SQL 运行时逐列计算得到的，因此它不得不进行表搜索，而没有使用该列上面的索引；如果这些结果在查询编译时就能得到，那么就可以被 SQL 优化器优化，使用索引，避免表搜索，因此将 SQL 重写成下面这样：
SELECT*FROMrecordWHEREcard_nolike'5378%'
（<1 秒）
SELECT*FROMrecordWHEREamount<1000*30
（<1 秒）
SELECT*FROMrecordWHEREdate='1999/12/01'
（<1 秒）
11存储过程中，采用临时表优化查询：
例
1．从 parven 表中按 vendor_num 的次序读数据：
SELECTpart_num， vendor_num ， priceFROMparvenORDERBYvendor_num
INTOtemppv_by_vn
这个语句顺序读parven （ 50 页），写一个临时表（ 50 页），并排序。假定排序的开销为 200 页，总共是 300 页。
2．把临时表和 vendor 表连接，把结果输出到一个临时表，并按 part_num 排序：
SELECTpv_by_vn，＊ vendor.vendor_numFROMpv_by_vn ， vendor
WHEREpv_by_vn.vendor_num=vendor.vendor_num
ORDERBYpv_by_vn.part_num
INTOTMPpvvn_by_pn
DROPTABLEpv_by_vn
这个查询读取pv_by_vn(50 页 ) ，它通过索引存取 vendor 表 1.5 万次，但由于按 vendor_num 次序排列，实际上只是通过索引顺序地读 vendor 表（ 40 ＋ 2=42 页），输出的表每页约 95 行，共 160 页。写并存取这些页引发 5 ＊ 160=800 次的读写，索引共读写 892 页。
3．把输出和 part 连接得到最后的结果：
SELECTpvvn_by_pn.＊， part.part_descFROMpvvn_by_pn ， part
WHEREpvvn_by_pn.part_num=part.part_num
DROPTABLEpvvn_by_pn
这样，查询顺序地读pvvn_by_pn(160 页 ) ，通过索引读 part 表 1.5 万次，由于建有索引，所以实际上进行 1772 次磁盘读写，优化比例为 30 ∶ 1 。 ~~ ANY和 SOME 操作符优化 :
优化器将跟随值列表的ANY 和 SOME 检索条件用等价的同等操作符和 “ OR ” 组成的表达式替换。
例如，优化器将如下所示的第一条语句用第二条语句替换：
sal>ANY(:first_sal,:second_sal)
sal>:first_salORsal>:second_sal
优化器将跟随子查询的ANY 和 SOME 检索条件转换成由 “ EXISTS ” 和一个相应的子查询组成的检索表达式。
例如，优化器将如下所示的第一条语句用第二条语句替换：
x>ANY(SELECTsalFROMempWHEREjob='ANALYST')
EXISTS(SELECTsalFROMempWHEREjob='ANALYST'ANDx>sal)
~~ ALL操作符优化 :
优化器将跟随值列表的ALL 操作符用等价的 “ = ” 和 “ AND ” 组成的表达式替换。例如：
sal>ALL(:first_sal,:second_sal)表达式会被替换为：
sal>:first_salANDsal>:second_sal
对于跟随子查询的ALL 表达式，优化器用 ANY 和另外一个合适的比较符组成的表达式替换。例如
x>ALL(SELECTsalFROMempWHEREdeptno=10)替换为：
NOT(x=ANY(SELECTsalFROMempWHEREdeptno=10))
接下来优化器会把第二个表达式适用ANY 表达式的转换规则转换为下面的表达式：
NOTEXISTS(SELECTsalFROMempWHEREdeptno=10ANDx<=sal)
~~ BETWEEN操作符优化 :
优化器总是用“ >= ” 和 “ <= ” 比较符来等价的代替 BETWEEN 操作符。
例如：优化器会把表达式salBETWEEN2000AND3000 用 sal>=2000ANDsal<=3000 来代替。
~~ NOT操作符优化 :
优化器总是试图简化检索条件以消除“ NOT ” 逻辑操作符的影响，这将涉及到 “ NOT ” 操作符的消除以及代以相应的比较运算符。
例如，优化器将下面的第一条语句用第二条语句代替：
NOTdeptno=(SELECTdeptnoFROMempWHEREename='TAYLOR')
deptno<>(SELECTdeptnoFROMempWHEREename='TAYLOR')
通常情况下一个含有NOT 操作符的语句有很多不同的写法，优化器的转换原则是使 “ NOT ” 操作符后边的子句尽可能的简单，即使可能会使结果表达式包含了更多的 “ NOT ” 操作符。
例如，优化器将如下所示的第一条语句用第二条语句代替：
NOT(sal<1000ORcommISNULL)
NOTsal<1000ANDcommISNOTNULLsal>=1000ANDcommISNOTNULL

SQL优化 34 条建议

(1)选择最有效率的表名顺序 ( 只在基于规则的优化器中有效 ) ：
ORACLE的解析器按照从右到左的顺序处理 FROM 子句中的表名， FROM 子句中写在最后的表 ( 基础表 drivingtable) 将被最先处理，在 FROM 子句中包含多个表的情况下 , 你必须选择记录条数最少的表作为基础表。如果有 3 个以上的表连接查询 , 那就需要选择交叉表 (intersectiontable) 作为基础表 , 交叉表是指那个被其他表所引用的表 .
(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) 例子：
DELETEFROMEMPEWHEREE.ROWID>(SELECTMIN(X.ROWID)
FROMEMPXWHEREX.EMP_NO=E.EMP_NO);
(9)用 TRUNCATE 替代 DELETE ：
当删除表中的记录时, 在通常情况下 , 回滚段 (rollbacksegments) 用来存放可以被恢复的信息 . 如果你没有 COMMIT 事务 ,ORACLE 会将数据恢复到删除之前的状态 ( 准确地说是恢复到执行删除命令之前的状况 ) 而当运用 TRUNCATE 时 , 回滚段不再存放任何可被恢复的信息 . 当命令运行后 , 数据不能被恢复 . 因此很少的资源被调用 , 执行时间也会很短 .( 译者按 :TRUNCATE 只在删除全表适用 ,TRUNCATE 是 DDL 不是 DML)
(10)尽量多使用 COMMIT ：
只要有可能, 在程序中尽量多使用 COMMIT, 这样程序的性能得到提高 , 需求也会因为 COMMIT 所释放的资源而减少 :
COMMIT所释放的资源 :
a.回滚段上用于恢复数据的信息 .
b.被程序语句获得的锁
c.redologbuffer中的空间
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 语句中 , 要特别注意减少对表的查询 . 例子：
SELECTTAB_NAMEFROMTABLESWHERE(TAB_NAME,DB_VER)=(SELECT
TAB_NAME,DB_VERFROMTAB_COLUMNSWHEREVERSION=604)
(13)通过内部函数提高 SQL 效率：
复杂的SQL 往往牺牲了执行效率 . 能够掌握上面的运用函数解决问题的方法在实际工作中是非常有意义的
(14)使用表的别名 (Alias) ：
当在SQL 语句中连接多个表时 , 请使用表的别名并把别名前缀于每个 Column 上 . 这样一来 , 就可以减少解析的时间并减少那些由 Column 歧义引起的语法错误 .
(15)用 EXISTS 替代 IN 、用 NOTEXISTS 替代 NOTIN ：
在许多基于基础表的查询中, 为了满足一个条件 , 往往需要对另一个表进行联接 . 在这种情况下 , 使用 EXISTS( 或 NOTEXISTS) 通常将提高查询的效率 . 在子查询中 ,NOTIN 子句将执行一个内部的排序和合并 . 无论在哪种情况下 ,NOTIN 都是最低效的 ( 因为它对子查询中的表执行了一个全表遍历 ). 为了避免使用 NOTIN, 我们可以把它改写成外连接 (OuterJoins) 或 NOTEXISTS.
例子：
(高效 )SELECT*FROMEMP( 基础表 )WHEREEMPNO>0ANDEXISTS(SELECT ‘ X'FROMDEPTWHEREDEPT.DEPTNO=EMP.DEPTNOANDLOC= ‘ MELB')
(低效 )SELECT*FROMEMP( 基础表 )WHEREEMPNO>0ANDDEPTNOIN(SELECTDEPTNOFROMDEPTWHERELOC= ‘ MELB')
(16)识别 ' 低效执行 ' 的 SQL 语句：
虽然目前各种关于SQL 优化的图形化工具层出不穷 , 但是写出自己的 SQL 工具来解决问题始终是一个最好的方法：
SELECTEXECUTIONS,DISK_READS,BUFFER_GETS,
ROUND((BUFFER_GETS-DISK_READS)/BUFFER_GETS,2)Hit_radio,
ROUND(DISK_READS/EXECUTIONS,2)Reads_per_run,
SQL_TEXT
FROMV$SQLAREA
WHEREEXECUTIONS>0
ANDBUFFER_GETS>0
AND(BUFFER_GETS-DISK_READS)/BUFFER_GETS<0.8
ORDERBY4DESC;
(17)用索引提高效率：
索引是表的一个概念部分, 用来提高检索数据的效率， ORACLE 使用了一个复杂的自平衡 B-tree 结构 . 通常 , 通过索引查询数据比全表扫描要快 . 当 ORACLE 找出执行查询和 Update 语句的最佳路径时 ,ORACLE 优化器将使用索引 . 同样在联结多个表时使用索引也可以提高效率 . 另一个使用索引的好处是 , 它提供了主键 (primarykey) 的唯一性验证 . 。那些 LONG 或 LONGRAW 数据类型 , 你可以索引几乎所有的列 . 通常 , 在大型表中使用索引特别有效 . 当然 , 你也会发现 , 在扫描小表时 , 使用索引同样能提高效率 . 虽然使用索引能得到查询效率的提高 , 但是我们也必须注意到它的代价 . 索引需要空间来存储 , 也需要定期维护 , 每当有记录在表中增减或索引列被修改时 , 索引本身也会被修改 . 这意味着每条记录的 INSERT,DELETE,UPDATE 将为此多付出 4,5 次的磁盘 I/O. 因为索引需要额外的存储空间和处理 , 那些不必要的索引反而会使查询反应时间变慢 . 。定期的重构索引是有必要的 . ：
ALTERINDEX<INDEXNAME>REBUILD<TABLESPACENAME>
18)用 EXISTS 替换 DISTINCT ：
当提交一个包含一对多表信息( 比如部门表和雇员表 ) 的查询时 , 避免在 SELECT 子句中使用 DISTINCT. 一般可以考虑用 EXIST 替换 ,EXISTS 使查询更为迅速 , 因为 RDBMS 核心模块将在子查询的条件一旦满足后 , 立刻返回结果 . 例子：
(低效 ):
SELECTDISTINCTDEPT_NO,DEPT_NAMEFROMDEPTD,EMPE
WHERED.DEPT_NO=E.DEPT_NO
(高效 ):
SELECTDEPT_NO,DEPT_NAMEFROMDEPTDWHEREEXISTS(SELECT‘ X'
FROMEMPEWHEREE.DEPT_NO=D.DEPT_NO);
(19)sql语句用大写的：
因为oracle 总是先解析 sql 语句，把小写的字母转换成大写的再执行
(20)在 java 代码中尽量少用连接符 “ ＋ ” 连接字符串！
(21)避免在索引列上使用 NOT ：
我们要避免在索引列上使用NOT,NOT 会产生在和在索引列上使用函数相同的影响 . 当 ORACLE ” 遇到 ” NOT, 他就会停止使用索引转而执行全表扫描 .
(22)避免在索引列上使用计算．
WHERE子句中，如果索引列是函数的一部分．优化器将不使用索引而使用全表扫描．
举例:
低效：
SELECT… FROMDEPTWHERESAL*12>25000;
高效:
SELECT… FROMDEPTWHERESAL>25000/12;
(23)用 >= 替代 >
高效:
SELECT*FROMEMPWHEREDEPTNO>=4
低效:
SELECT*FROMEMPWHEREDEPTNO>3
两者的区别在于, 前者 DBMS 将直接跳到第一个 DEPT 等于 4 的记录而后者将首先定位到 DEPTNO=3 的记录并且向前扫描到第一个 DEPT 大于 3 的记录 .
(24)用 UNION 替换 OR( 适用于索引列 )
通常情况下, 用 UNION 替换 WHERE 子句中的 OR 将会起到较好的效果 . 对索引列使用 OR 将造成全表扫描 . 注意 , 以上规则只针对多个索引列有效 . 如果有 column 没有被索引 , 查询效率可能会因为你没有选择 OR 而降低 . 在下面的例子中 ,LOC_ID 和 REGION 上都建有索引 .
高效:
SELECTLOC_ID,LOC_DESC,REGION
FROMLOCATION
WHERELOC_ID=10
UNION
SELECTLOC_ID,LOC_DESC,REGION
FROMLOCATION
WHEREREGION=“ MELBOURNE ”
低效:
SELECTLOC_ID,LOC_DESC,REGION
FROMLOCATION
WHERELOC_ID=10ORREGION=“ MELBOURNE ”
如果你坚持要用OR, 那就需要返回记录最少的索引列写在最前面 .
(25)用 IN 来替换 OR
这是一条简单易记的规则，但是实际的执行效果还须检验，在ORACLE8i 下，两者的执行路径似乎是相同的．　
低效:
SELECT… .FROMLOCATIONWHERELOC_ID=10ORLOC_ID=20ORLOC_ID=30
高效
SELECT… FROMLOCATIONWHERELOC_ININ(10,20,30);
(26)避免在索引列上使用 ISNULL 和 ISNOTNULL
避免在索引中使用任何可以为空的列，ORACLE 将无法使用该索引．对于单列索引，如果列包含空值，索引中将不存在此记录 . 对于复合索引，如果每个列都为空，索引中同样不存在此记录 . 　如果至少有一个列不为空，则记录存在于索引中．举例 : 如果唯一性索引建立在表的 A 列和 B 列上 , 并且表中存在一条记录的 A,B 值为 (123,null),ORACLE 将不接受下一条具有相同 A,B 值 (123,null) 的记录 ( 插入 ). 然而如果所有的索引列都为空， ORACLE 将认为整个键值为空而空不等于空 . 因此你可以插入 1000 条具有相同键值的记录 , 当然它们都是空 ! 因为空值不存在于索引列中 , 所以 WHERE 子句中对索引列进行空值比较将使 ORACLE 停用该索引 .
低效:( 索引失效 )
SELECT… FROMDEPARTMENTWHEREDEPT_CODEISNOTNULL;
高效:( 索引有效 )
SELECT… FROMDEPARTMENTWHEREDEPT_CODE>=0;
(27)总是使用索引的第一个列：
如果索引是建立在多个列上, 只有在它的第一个列 (leadingcolumn) 被 where 子句引用时 , 优化器才会选择使用该索引 . 这也是一条简单而重要的规则，当仅引用索引的第二个列时 , 优化器使用了全表扫描而忽略了索引
28)用 UNION-ALL 替换 UNION( 如果有可能的话 ) ：
当SQL 语句需要 UNION 两个查询结果集合时 , 这两个结果集合会以 UNION-ALL 的方式被合并 , 然后在输出最终结果前进行排序 . 如果用 UNIONALL 替代 UNION, 这样排序就不是必要了 . 效率就会因此得到提高 . 需要注意的是， UNIONALL 将重复输出两个结果集合中相同记录 . 因此各位还是要从业务需求分析使用 UNIONALL 的可行性 .UNION 将对结果集合排序 , 这个操作会使用到 SORT_AREA_SIZE 这块内存 . 对于这块内存的优化也是相当重要的 . 下面的 SQL 可以用来查询排序的消耗量
低效：
SELECTACCT_NUM,BALANCE_AMT
FROMDEBIT_TRANSACTIONS
WHERETRAN_DATE='31-DEC-95'
UNION
SELECTACCT_NUM,BALANCE_AMT
FROMDEBIT_TRANSACTIONS
WHERETRAN_DATE='31-DEC-95'
高效:
SELECTACCT_NUM,BALANCE_AMT
FROMDEBIT_TRANSACTIONS
WHERETRAN_DATE='31-DEC-95'
UNIONALL
SELECTACCT_NUM,BALANCE_AMT
FROMDEBIT_TRANSACTIONS
WHERETRAN_DATE='31-DEC-95'
(29)用 WHERE 替代 ORDERBY ：
ORDERBY子句只在两种严格的条件下使用索引 .
ORDERBY中所有的列必须包含在相同的索引中并保持在索引中的排列顺序 .
ORDERBY中所有的列必须定义为非空 .
WHERE子句使用的索引和 ORDERBY 子句中所使用的索引不能并列 .
例如:
表DEPT 包含以下列 :
DEPT_CODEPKNOTNULL
DEPT_DESCNOTNULL
DEPT_TYPENULL
低效:( 索引不被使用 )
SELECTDEPT_CODEFROMDEPTORDERBYDEPT_TYPE
高效:( 使用索引 )
SELECTDEPT_CODEFROMDEPTWHEREDEPT_TYPE>0
(30)避免改变索引列的类型 :
当比较不同数据类型的数据时,ORACLE 自动对列进行简单的类型转换 .
假设EMPNO 是一个数值类型的索引列 .
SELECT… FROMEMPWHEREEMPNO= ‘ 123'
实际上, 经过 ORACLE 类型转换 , 语句转化为 :
SELECT… FROMEMPWHEREEMPNO=TO_NUMBER( ‘ 123')
幸运的是, 类型转换没有发生在索引列上 , 索引的用途没有被改变 .
现在, 假设 EMP_TYPE 是一个字符类型的索引列 .
SELECT… FROMEMPWHEREEMP_TYPE=123
这个语句被ORACLE 转换为 :
SELECT… FROMEMPWHERETO_NUMBER(EMP_TYPE)=123
因为内部发生的类型转换, 这个索引将不会被用到 ! 为了避免 ORACLE 对你的 SQL 进行隐式的类型转换 , 最好把类型转换用显式表现出来 . 注意当字符和数值比较时 ,ORACLE 会优先转换数值类型到字符类型
(31)需要当心的 WHERE 子句 :
某些SELECT 语句中的 WHERE 子句不使用索引 . 这里有一些例子 .
在下面的例子里,
(1)‘ !=' 将不使用索引 . 记住 , 索引只能告诉你什么存在于表中 , 而不能告诉你什么不存在于表中 .
(2)‘ ||' 是字符连接函数 . 就象其他函数那样 , 停用了索引 .
(3)‘ +' 是数学函数 . 就象其他数学函数那样 , 停用了索引 .
(4)相同的索引列不能互相比较 , 这将会启用全表扫描 .

(32)
a.如果检索数据量超过 30% 的表中记录数 . 使用索引将没有显著的效率提高 .
b.在特定情况下 , 使用索引也许会比全表扫描慢 , 但这是同一个数量级上的区别 . 而通常情况下 , 使用索引比全表扫描要块几倍乃至几千倍 !
(33)避免使用耗费资源的操作 :
带有DISTINCT,UNION,MINUS,INTERSECT,ORDERBY 的 SQL 语句会启动 SQL 引擎
执行耗费资源的排序(SORT) 功能 .DISTINCT 需要一次排序操作 , 而其他的至少需要执行两次排序 . 通常 , 带有 UNION,MINUS,INTERSECT 的 SQL 语句都可以用其他方式重写 . 如果你的数据库的 SORT_AREA_SIZE 调配得好 , 使用 UNION,MINUS,INTERSECT 也是可以考虑的 , 毕竟它们的可读性很强
(34)优化 GROUPBY:
提高GROUPBY 语句的效率 , 可以通过将不需要的记录在 GROUPBY 之前过滤掉 . 下面两个查询返回相同结果但第二个明显就快了许多 .
低效:
SELECTJOB,AVG(SAL)
FROMEMP
GROUPbyJOB
HAVINGJOB=‘ PRESIDENT'
ORJOB=‘ MANAGER'
高效:
SELECTJOB,AVG(SAL)
FROMEMP
WHEREJOB=‘ PRESIDENT'
ORJOB=‘ MANAGER'
GROUPbyJOB