下面这篇文章来自某微信公众号,作者收集了oracle 较早版本的一些SQL优化"技巧",文章标题起的很是诱人.
我认真的拜读了这篇文章, 发现其中很多说法已经严重过时,或者说本来就是错误的理论, 这样的文章, 如果不加以纠正, 而且被更多的人转发传播,会误导很多DBA和SQL开发人员. 这些所谓的知识点, 他们不是学会了, 而是学废了.
下面是文章原文和我的点评, 我的点评以tiger开头,字体颜色为红色.
ORACLE的优化器共有3种：
a.RULE (基于规则)
b.COST (基于成本)
c.CHOOSE (选择性)
设置缺省的优化器，可以通过对init.ora中OPTIMIZER_MODE参数的各种声明，如RULE，COST，CHOOSE，ALL_ROWS，FIRST_ROWS，你当然也在SQL句级或是会话(session)级对其进行覆盖。
为了使用基于成本的优化器(CBO，Cost-based Optimizer)，你必须经常运行analyze命令，以增加数据库中的对象统计信息(object statistics)的准确性。
如果数据库的优化器模式设置为选择性(CHOOSE)，那么实际的优化器模式将和是否运行过Analyze命令有关。
如果Table已经被Analyze过，优化器模式将自动成为CBO，反之，数据库将采用RULE形式的优化器。
在缺省情况下，ORACLE采用CHOOSE优化器，为了避免那些不必要的全表扫描(full table scan)，你必须尽量避免使用CHOOSE优化器，而直接采用基于成本的优化器。
tiger:
oracle 版本10g(2003年发布)开始,默认和推荐的OPTIMIZER_MODE就是ALL_ROWS了(CBO), 并声明不再支持过时的RBO. 这一条说的是9i及之前版本的特征,已经过去了18年,过时的知识点就不要再提了,除非你要研究古董数据库.技术文章也要与时俱进才行.
这里大家记住, 现在的优化器是聪明的CBO,而不是过时的RBO就行了.下面的点评还会提到这两个术语.
ORACLE采用两种访问表中记录的方式：
a.全表扫描全表扫描就是顺序地访问表中每条记录. ORACLE采用一次读入多个数据块(data block)的方式优化全表扫描.
b.通过ROWID访问表你可以采用基于ROWID的访问方式情况，提高访问表的效率，ROWID包含了表中记录的物理位置信息，ORACLE采用索引(INDEX)实现了数据和存放数据的物理位置(ROWID)之间的联系。通常索引提供了快速访问ROWID的方法，因此那些基于索引列的查询就可以得到性能上的提高。
tiger:
认为使用索引就比全表扫描效率高的思想是错误的,索引适合访问表上少量的记录,如果要访问表上的大部分记录,走索引反而是低效的.
如果有t表的status字段,只有两个值0和1, 0对应的记录数比较少, 1对应大部分记录,在status字段上创建了索引,那么 select * from t where status=0 走索引是高效的, 而select * from t where status=1 走索引就是低效的,还不如全表扫描.
补充:如果是古老的RBO,只要有索引就会使用不管是否高效;而CBO是有选择的使用,status=0 的时候选择使用索引, status=1的时候不选择使用索引. RBO为什么会被淘汰, 这是原因之一.
为了不重复解析相同的SQL语句，在第一次解析之后，ORACLE将SQL语句存放在内存中。
这块位于系统全局区域SGA(System GlobalArea)的共享池(Shared Buffer Pool)中的内存可以被所有的数据库用户共享。
因此，当你执行一个SQL语句(有时被称为一个光标)时，如果它和之前的执行过的语句完全相同，ORACLE就能很快获得已经被解析的语句以及最好的执行路径。
ORACLE的这个功能大大地提高了SQL的执行性能并节省了内存的使用。可惜的是ORACLE只对简单的表提供高速缓冲(cache buffering)，这个功能并不适用于多表连接查询。
数据库管理员必须在init.ora中为这个区域设置合适的参数，当这个内存区域越大，就可以保留更多的语句，当然被共享的可能性也就越大了。
当你向ORACLE 提交一个SQL语句，ORACLE会首先在这块内存中查找相同的语句。
这里需要注明的是，ORACLE对两者采取的是一种严格匹配，要达成共享，SQL语句必须完全相同(包括空格，换行等).
共享的语句必须满足三个条件：
A.字符级的比较：当前被执行的语句和共享池中的语句必须完全相同.例如：
SELECt * FROM EMP;
和下列每一个都不同
SELECt * from EMP;Select * From Emp;SELECt * FROM EMP;
B.两个语句所指的对象必须完全相同
C.两个SQL语句中必须使用相同的名字的绑定变量(bind variables)例如：第一组的两个SQL语句是相同的(可以共享)，而第二组中的两个语句是不同的(即使在运行时，赋于不同的绑定变数相同的值)
a.
selectpin ,name from people where pin = :blk1.pin;
selectpin ,name from people where pin = :blk1.pin;
b.
selectpin ,name from people where pin = :blk1.ot_ind;
selectpin ,name from people where pin = :blk1.ov_ind;
tiger:
可以总结为一句话,OLTP业务,为了共享SQL,减少硬解析的时间和资源的消耗,建议合理使用绑定变量的写法. 注意合理两个字, 不是所有的变量都建议使用绑定变量.
ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，因此FROM子句中写在最后的表(基础表driving table)将被最先处理.
在FROM子句中包含多个表的情况下，你必须选择记录条数最少的表作为基础表.
当ORACLE处理多个表时，会运用排序及合并的方式连接它们.首先，扫描第一个表(FROM子句中最后的那个表)并对记录进行派序，然后扫描第二个表(FROM子句中最后第二个表)，最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并.
例如：表 TAB1 16384 条记录表 TAB2 1条记录选择TAB1作为基础表 (最好的方法)
select count(*) from tab1，tab2 执行时间0.96秒选择TAB2作为基础表 (不佳的方法)
select count(*) from tab2，tab1 执行时间26.09秒
如果有3个以上的表连接查询，那就需要选择交叉表(inter section table)作为基础表，交叉表是指那个被其它表所引用的表.
例如：
EMP表描述了LOCATION表和CATEGORY表的交集.
SELECt * FROM LOCATION L, CATEGORY C, EMP E WHERe E.EMP_NO BETWEEN 1000 AND 2000 AND E.CAT_NO = C.CAT_NO AND E.LOCN = L.LOCN
将比下列SQL更有效率
SELECt *
FROM EMP E, LOCATION L ,CATEGORY C
WHERe E.CAT_NO = C.CAT_NO AND E.LOCN = L.LOCN
AND E.EMP_NO BETWEEN 1000 AND 2000;
tiger:
已经过时很久的规则(RBO规则),基本上现在生产上很少有9i之前的版本了.在10g及之后版本默认CBO规则下,表的顺序随便写,优化器会根据统计信息,自动选择关联顺序和关联方法.
正是因为这些过时文章的存在,现在还有很多人经常问我这个问题.因为很多开发人员不知道什么是基于规则的优化器.
ORACLE采用自下而上的顺序解析WHERe子句，根据这个原理，表之间的连接必须写在其它WHERe条件之前，那些可以过滤掉最大数量记录的条件必须写在WHERe子句的末尾.
例如：(低效，执行时间156.3秒)
SELECt ... FROM EMP E WHERe SAL > 50000 AND JOB = 'MANAGER' AND 25 < (SELECt COUNT(*) FROM EMP WHERe MGR=E.EMPNO);(高效，执行时间10.6秒)
SELECt ... FROM EMP E WHERe 25 < (SELECt COUNT(*) FROM EMP WHERe MGR=E.EMPNO) AND SAL > 50000 AND JOB = 'MANAGER'; tiger:
同第4条一样, CBO下谓词条件的顺序可以随便写. 上面高效的写法可能也是低效的,where 部分存在标量子查询的写法.
当你想在SELECt子句中列出所有的COLUMN时，使用动态SQL列引用 '*' 是一个方便的方法.不幸的是，这是一个非常低效的方法。
实际上，ORACLE在解析的过程中，会将'*' 依次转换成所有的列名，这个工作是通过查询数据字典完成的，这意味着将耗费更多的时间.
tiger: 不使用 select * 的理由有多个, 唯独不是上面说的这个原因, 我总结了几个影响性能的原因如下:
当执行每条SQL语句时，ORACLE在内部执行了许多工作：解析SQL语句，估算索引的利用率，绑定变数，读数据块等等.
由此可见，减少访问数据库的次数，就能实际上减少ORACLE的工作量.
例如，以下有三种方法可以检索出雇员号等于0342或0291的职员.
方法1 (最低效)
SELECT EMP_NAME ，SALARY ，GRADE FROM EMP WHERe EMP_NO= 342;
方法2 (次低效)
DECLARE CURSOR C1 (E_NO NUMBER) ISSELECt EMP_NAME, SALARY, GRADE FROM EMP WHERe EMP_NO = E_NO; BEGIN OPEN C1(342); FETCH C1 INTO…,..,.. ; CLOSE C1;END;
方法3 (高效)
SELECt A.EMP_NAME ,A.SALARY ,A.GRADE，B.EMP_NAME,B.SALARY ,B.GRADE FROM EMP A，EMP B WHERe A.EMP_NO = 342 AND B.EMP_NO = 291;
注意：在SQL*Plus ，SQL*Forms和Pro*C中重新设置ArraySize参数，可以增加每次数据库访问的检索数据量，建议值为200.
tiger: 方法3的"高效"写法不知道是谁发明出来的,可以称之为奇葩写法. 我建议写成下面形式: SELECt EMP_NAME ，SALARY ，GRADE FROM EMP WHERe EMP_NO in (342,291); 设置arraysize的说法倒是没问题, sqlplus默认是15,jdbc默认是10, 改成100会好一些,这个没有官方建议值.
使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表.例如：
SELECt COUNT(*)，SUM(SAL) FROM EMP WHERe DEPT_NO = 0020 AND ENAME LIKE 'SMITH%'; SELECt COUNT(*)，SUM(SAL) FROM EMP WHERe DEPT_NO = 0030 AND ENAME LIKE 'SMITH%';
你可以用DECODE函数高效地得到相同结果
SELECt COUNT(DECODE(DEPT_NO，0020，'X'，NULL))D0020_COUNT， COUNT(DECODE(DEPT_NO，0030，'X'，NULL))D0030_COUNT， SUM(DECODE(DEPT_NO，0020，SAL，NULL)) D0020_SAL， SUM(DECODE(DEPT_NO，0030，SAL，NULL)) D0030_SALFROM EMPWHERe ENAME LIKE 'SMITH%';类似的，DECODE函数也可以运用于GROUP BY 和ORDER BY子句中.
tiger:
理论是正确的,但是例子和写法看着有点蹩脚,写成下面方式不好吗?
select dept_no,count(*),sum(sal)
from emp
where dept_no in(20,30) and ename like 'SMITH%'
group by dept_no;
如果你有几个简单的数据库查询语句，你可以把它们整合到一个查询中(即使它们之间没有关系)例如：
SELECt NAME FROM EMP WHERe EMP_NO = 1234; SELECt NAME FROM DPT WHERe DPT_NO = 10 ; SELECt NAME FROM CAT WHERe CAT_TYPE = 'RD';
上面的3个查询可以被合并成一个：
SELECt E.NAME ,D.NAME ,C.NAME FROMCAT C, DPT D, EMP E, DUAL X WHERe NVL('X'，X.DUMMY) = NVL('X'，E.ROWID(+)) AND NVL('X'，X.DUMMY) = NVL('X'，D.ROWID(+)) AND NVL('X'，X.DUMMY) = NVL('X'，C.ROWID(+)) AND E.EMP_NO(+) = 1234 AND D.DEPT_NO(+) = 10 AND C.CAT_TYPE(+) = 'RD';
虽然采取这种方法，效率得到提高，但是程序的可读性大大降低，所以读者还是要权衡之间的利弊)
tiger:
这个SQL改写方法更是奇葩中的奇葩, 本来就是几个正常的SQL, 把几个无关SQL改成谁都看不懂的合并写法当优化写法, 这是走火入魔了吧!
最高效的删除重复记录方法 (因为使用了ROWID)
DELETe FROM EMP E WHERe E.ROWID > (SELECt MIN(X.ROWID)FROM EMP X WHERe X.EMP_NO = E.EMP_NO);
tiger:
可以说是删除重复记录的一种方法,但不一定是最高效.而且有的时候还要根据不同的条件保留所需的记录,这样就没办法用到rowid.
大表或重复记录多的情况, CTAS创建新表再rename,也是一个不错的选择.
当删除表中的记录时，在通常情况下，回滚段(rollback segments ) 用来存放可以被恢复的信息.
如果你没有COMMIT事务，ORACLE会将数据恢复到删除之前的状态(准确地说是恢复到执行删除命令之前的状况)
而当运用TRUNCATE时，回滚段不再存放任何可被恢复的信息.当命令运行后，数据不能被恢复.因此很少的资源被调用，执行时间也会很短。
(TRUNCATE只在删除全表适用，TRUNCATE是DDL不是DML)
tiger:
这个理论是正确的. 准确的说法应该是删除全表数据时, 建议使用truncate而不是使用不加where条件的delete.
只要有可能，在程序中尽量多使用COMMIT，这样程序的性能得到提高，需求也会因为COMMIT所释放的资源而减少：
COMMIT所释放的资源：
a.回滚段上用于恢复数据的信息.
b.被程序语句获得的锁
c.redo log buffer 中的空间
d.ORACLE为管理上述3种资源中的内部花费
(在使用COMMIT时必须要注意到事务的完整性，现实中效率和事务完整性往往是鱼和熊掌不可得兼)
tiger:
在批处理情况下, commit频率要适中, 每500条或1000条 commit一次(根据情况), 如果每次都commit, 执行效率会大大下降.
和一般的观点相反，count(*) 比count(1)稍快 ，当然如果可以通过索引检索，对索引列的计数仍旧是最快的. 例如 COUNT(EMPNO)(通过实际的测试，上述三种方法并没有显着的性能差别)
tiger:
count(*) 与count(1)是等价的, 与count(not null column) 也是等价的; 如果empno 的字段定义是可为空, 是不等价的, 放在一起比较是没有意义的;
count(not null column) 快的原因是因为表上有not null字段上的索引,使用了index fast full scan,由于索引占用的空间一般都比表小, 所以扫描索引比较扫描表会快. 用测试来验证理论, 而不是用测试结果得出理论!
避免使用HAVINg子句，
HAVINg 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序，总计等操作.
如果能通过WHERe子句限制记录的数目，那就能减少这方面的开销.
例如：低效：
SELECT REGION，AVG(LOG_SIZE) FROM LOCATION GROUP BY REGION HAVINg REGION REGION != 'SYDNEY'AND REGION != 'PERTH';
高效
SELECt REGION，AVG(LOG_SIZE) FROM LOCATION WHERe REGION REGION != 'SYDNEY' AND REGION != 'PERTH' GROUP BY REGION;
(HAVINg 中的条件一般用于对一些集合函数的比较，如COUNT() 等等. 除此而外，一般的条件应该写在WHERe子句中)
在含有子查询的SQL语句中，要特别注意减少对表的查询.例如：
低效
SELECt TAB_NAMEFROM TABLESWHERe TAB_NAME = ( SELECt TAB_NAME FROM TAB_COLUMNS WHERe VERSION = 604) AND DB_VER= ( SELECt DB_VER FROM TAB_COLUMNS WHERe VERSION = 604)
高效
SELECt TAB_NAMEFROM TABLESWHERe (TAB_NAME, DB_VER) = ( SELECt TAB_NAME, DB_VER) FROM TAB_COLUMNS WHERe VERSION =604)
Update 多个Column 例子：
低效：
UPDATE EMP SET EMP_CAT = (SELECT MAX(CATEGORY) FROM EMP_CATEGORIES)，SAL_RANGE= (SELECt MAX(SAL_RANGE) FROM EMP_CATEGORIES)WHERe EMP_DEPT = 0020;
高效：
UPDATe EMP SET (EMP_CAT，SAL_RANGE) = (SELECT MAX(CATEGORY) ,MAX(SAL_RANGE) FROM EMP_CATEGORIES)WHERe EMP_DEPT = 0020;
SELECt H.EMPNO，E.ENAME，H.HIST_TYPE，T.TYPE_DESC，COUNT(*)FROM HISTORY_TYPE T，EMP E，EMP_HISTORY H WHEReH.EMPNO = E.EMPNO AND H.HIST_TYPE = T.HIST_TYPE GROUP BY H.EMPNO，E.ENAME，H.HIST_TYPE，T.TYPE_DESC;
通过调用下面的函数可以提高效率.
FUNCTION LOOKUP_HIST_TYPE(TYP IN NUMBER) RETURN VARCHAR2AS TDESC VARCHAr2(30); CURSOR C1 IS SELECt TYPE_DESC FROM HISTORY_TYPE WHERe HIST_TYPE = TYP;BEGIN OPEN C1; FETCH C1 INTO TDESC; CLOSE C1; RETURN (NVL(TDESC，'?'));END;
FUNCTION LOOKUP_EMP(EMP IN NUMBER) RETURN VARCHAR2AS ENAME VARCHAr2(30); CURSOR C1 IS SELECt ENAME FROM EMP WHERe EMPNO=EMP;BEGIN OPEN C1; FETCH C1 INTO ENAME; CLOSE C1; RETURN (NVL(ENAME，'?'));END; sql变成:
SELECt H.EMPNO，LOOKUP_EMP(H.EMPNO)，H.HIST_TYPE，
LOOKUP_HIST_TYPE(H.HIST_TYPE)，COUNT(*)
FROM EMP_HISTORY H
GROUP BY H.EMPNO ，H.HIST_TYPE;
(经常在论坛中看到如 '能不能用一个SQL写出….' 的贴子，殊不知复杂的SQL往往牺牲了执行效率. 能够掌握上面的运用函数解决问题的方法在实际工作中是非常有意义的)
tiger:
为了一个查询还要创建两个函数,太复杂了吧. 不用函数, 先只对EMP_HISTORY做group by,再与其他两个小表做关联,与使用函数的原理是一样的, 效率比使用函数的写法还要高.
当在SQL语句中连接多个表时，请使用表的别名并把别名前缀于每个Column上.这样一来，就可以减少解析的时间并减少那些由Column歧义引起的语法错误.
(Column歧义指的是由于SQL中不同的表具有相同的Column名，当SQL语句中出现这个Column时，SQL解析器无法判断这个Column的归属)
tiger:
使用别名是个好习惯,应该写到开发规范里面. 但是使用别名主要是为了避免相同column导致的逻辑错误,解析时间和语法错误是次要的.
在许多基于基础表的查询中，为了满足一个条件，往往需要对另一个表进行联接.在这种情况下，使用EXISTS(或NOT EXISTS)通常将提高查询的效率.
低效：
SELECt *FROM EMP (基础表)WHERe EMPNO > 0AND DEPTNO IN (SELECt DEPTNOFROM DEPTWHERe LOC = 'MELB')
高效：
SELECt *FROM EMP (基础表)WHERe EMPNO > 0AND EXISTS (SELECt 'X'FROM DEPTWHERe DEPT.DEPTNO = EMP.DEPTNOAND LOC = 'MELB')
相对来说，用NOT EXISTS替换NOT IN 将更显着地提高效率。
tiger:
in和exists在大部分情况下效率是相同的(比如上面写法), 只在少数特殊情况不太一样;
not in和not exists是不等价的, 一般情况下建议使用not exists, 需要注意关联字段是否为null,主查询关联字段值为null时的记录是否需要返回.
在子查询中，NOT IN子句将执行一个内部的排序和合并.
无论在哪种情况下，NOT IN都是最低效的 (因为它对子查询中的表执行了一个全表遍历).
为了避免使用NOT IN ，我们可以把它改写成外连接(Outer Joins)或NOT EXISTS.
例如：
SELECt … FROM EMP WHERe DEPT_NO NOT IN (SELECt DEPT_NO FROM DEPT WHERe DEPT_CAT='A');
为了提高效率.改写为：
(方法一：高效)
SELECt….FROM EMP A，DEPT BWHERe A.DEPT_NO = B.DEPT(+)AND B.DEPT_NO IS NULLAND B.DEPT_CAT(+) = 'A'
(方法二：最高效)
SELECt …FROM EMP EWHERe NOT EXISTS (SELECt 'X' FROM DEPT D WHERe D.DEPT_NO = E.DEPT_NO AND DEPT_CAT = 'A');
tiger:
not in和not exists在关联字段不全是not null的情况下不能等价改写; 外关联的写法与not exists是等价的,与not in不等价;
通常来说 ，采用表连接的方式比EXISTS更有效率
SELECt ENAME FROM EMP E WHERe EXISTS (SELECt 'X' FROM DEPT WHERe DEPT_NO = E.DEPT_NO AND DEPT_CAT = 'A'); 高效: SELECt ENAME FROM DEPT D，EMP E WHERe E.DEPT_NO = D.DEPT_NO AND DEPT_CAT = 'A' ; tiger: 只有子查询表的关联字段值唯一的情况下,上面的改写才是等价的; 否则改写出来的结果集会比原结果集大, 千万别被上面这个不等价改写误导!
当提交一个包含一对多表信息(比如部门表和雇员表)的查询时，避免在SELECt子句中使用DISTINCT. 一般可以考虑用EXIST替换 例如：
低效：
SELECT DISTINCT DEPT_NO，DEPT_NAME FROM DEPT D，EMP E WHERe D.DEPT_NO = E.DEPT_NO; 高效：
SELECt DEPT_NO，DEPT_NAME FROM DEPT D WHERe EXISTS ( SELECt 'X' FROM EMP E WHERe E.DEPT_NO =D.DEPT_NO);EXISTS 使查询更为迅速，因为RDBMS核心模块将在子查询的条件一旦满足后，立刻返回结果.
tiger:
这个改写是不等价的,网上和书上很多文章都这么写, 一般都是把下面sql改写成上面. 一个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_TEXTFROM V$SQLAREAWHERe EXECUTIONS>0AND BUFFER_GETS > 0AND (BUFFER_GETS-DISK_READS)/BUFFER_GETS < 0.8ORDERBY 4 DESC;虽然目前各种关于SQL优化的图形化工具层出不穷，但是写出自己的SQL工具来解决问题始终是一个最好的方法
tiger:
低效索引也会产生比较少的disk_reads, 用这个sql来查找低效sql, 得到的结果比较片面. 建议分维度(执行时间,cpu消耗,逻辑读,物理读等)列出top sql, 逐一分析.
SQL trace 工具收集正在执行的SQL的性能状态数据并记录到一个跟踪文件中.这个跟踪文件提供了许多有用的信息，
例如解析次数.执行次数，CPU使用时间等.这些数据将可以用来优化你的系统.
设置SQL TRACE在会话级别：有效
ALTER SESSION SET SQL_TRACE=TRUE;设置SQL TRACE 在整个数据库有效，你必须将SQL_TRACE参数在init.ora中设为TRUE，
USER_DUMP_DEST参数说明了生成跟踪文件的目录
四个步骤：
(1) 设置user_dump_dest的路径
(2) 设置time_statistics=true 也可用alter system
(3) max_dump_file_size设得较大或用alter system设置为unlimited
(4) alter session set sql_trace=true
tiger:
古老的工具和方法,在较早的版本用得比较多. 设置sql_trace得到的信息比较少,相当于10046 trace的level 1, 一般10046 trace都会设置level 12(增加绑定变量和等待事件的信息).
EXPLAIN PLAN 是一个很好的分析SQL语句的工具，它甚至可以在不执行SQL的情况下分析语句.
通过分析，我们就可以知道ORACLE是怎么样连接表，使用什么方式扫描表(索引扫描或全表扫描)以及使用到的索引名称.
你需要按照从里到外，从上到下的次序解读分析的结果. EXPLAIN PLAN分析的结果是用缩进的格式排列的，最内部的操作将被最先解读，如果两个操作处于同一层中，带有最小操作号的将被首先执行.
NESTED LOOP是少数不按照上述规则处理的操作，正确的执行路径是检查对NESTED LOOP提供数据的操作，其中操作号最小的将被最先处理.
举例：
SQL>@D:oracleora90 dbmsadmin?lan.sqlSQL> @D:oracleora90sqlplusadminplustrce.sqlSQL>list 1 SELECt * 2 FROMdept，emp 3* WHERe emp.deptno = dept.deptno;SQL> set autotrace traceonly SQL>set timing on 显示执行时间// SQL>set autorace on 显示执行计划// SQL>set autotrace traceonly只显示执行计划即不显示查询出来的数据SQL>/14rows selected.ExecutionPlan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE 1 0 NESTED LOOPS 2 1 TABLE ACCESS (FULL) OF 'EMP' 3 1 TABLE ACCESS (BY INDEX ROWID)OF 'DEPT' 4 3 INDEX (UNIQUE SCAN) OF'PK_DEPT' (UNIQUE)Statistics---------------------------------------------------------- 0 recursive calls 2 db block gets 30 consistent gets 0 physical reads 0 redo size 2598 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 14 rows processed
通过以上分析，可以得出实际的执行步骤是：
1.TABLEACCESS (FULL) OF 'EMP'
2.INDEX(UNIQUE SCAN) OF 'PK_DEPT' (UNIQUE)
3.TABLEACCESS (BY INDEX ROWID) OF 'DEPT'
4.NESTEDLOOPS (JOINING 1 AND 3)
tiger:
nested loops的执行计划没有什么特殊之处;
set autotrace on一般是要执行SQL(只有set autotrace traceonly exp, select语句才不执行,但dml语句还是会执行);
explain plan 是不执行SQL, 得到的执行计划与autotrae 一样,都不一定是真实的执行计划.
索引是表的一个概念部分，用来提高检索数据的效率.
实际上，ORACLE使用了一个复杂的自平衡B-tree结构. 通常，通过索引查询数据比全表扫描要快.
当ORACLE找出执行查询和Update语句的最佳路径时，ORACLE优化器将使用索引. 同样在联结多个表时使用索引也可以提高效率.
另一个使用索引的好处是，它提供了主键(primary key)的唯一性验证.除了那些LONG或LONG RAW数据类型，你可以索引几乎所有的列.
通常，在大型表中使用索引特别有效. 当然，你也会发现，在扫描小表时，使用索引同样能提高效率.
虽然使用索引能得到查询效率的提高，但是我们也必须注意到它的代价. 索引需要空间来存储，也需要定期维护，每当有记录在表中增减或索引列被修改时，索引本身也会被修改.
这意味着每条记录的INSERT ，DELETE，UPDATE将为此多付出4 ，5 次的磁盘I/O .
因为索引需要额外的存储空间和处理，那些不必要的索引反而会使查询反应时间变慢
定期的重构索引是有必要的.
ALTER INDEX <INDEXNAME> REBUILD <TABLESPACENAME>;
tiger:
查询少量数据索引快,查询大量数据全表扫描快! delete和update一般情况下也是需要使用索引的,同时维护索引的开销要比全表扫描少很多;定期的rebuild索引不是必需的, 频繁的update和delete操作, 可能需要rebuild.
ORACLE对索引有两种访问模式.
1.索引唯一扫描 ( INDEX UNIQUE SCAN)
大多数情况下，优化器通过WHERe子句访问INDEX.
例如：表LODGING有两个索引 ：
建立在LODGING列上的唯一性索引LODGING_PK和建立在MANAGER列上的非唯一性索引LODGING$MANAGER.
SELECT * FROM LODGING WHERe LODGING = 'ROSE HILL';
在内部 ，上述SQL将被分成两步执行，首先 ，LODGING_PK 索引将通过索引唯一扫描的方式被访问，获得相对应的ROWID，通过ROWID访问表的方式 执行下一步检索.
如果被检索返回的列包括在INDEX列中，ORACLE将不执行第二步的处理(通过ROWID访问表). 因为检索数据保存在索引中，单单访问索引就可以完全满足查询结果.
下面SQL只需要INDEX UNIQUE SCAN 操作.
SELECt LODGING FROM LODGING WHERe LODGING = 'ROSE HILL';
2.索引范围查询(INDEX RANGE SCAN)
适用于两种情况：1.基于一个范围的检索2.基于非唯一性索引的检索例1：
SELECt LODGING FROM LODGING WHERe LODGING LIKE 'M%';
WHERe子句条件包括一系列值，ORACLE将通过索引范围查询的方式查询LODGING_PK . 由于索引范围查询将返回一组值，它的效率就要比索引唯一扫描低一些.例2：
SELECt LODGING FROM LODGING WHERe MANAGER = 'BILL GATES';
这个SQL的执行分两步，LODGING$MANAGER的索引范围查询(得到所有符合条件记录的ROWID) 和下一步通过ROWID访问表得到LODGING列的值.
由于LODGING$MANAGER是一个非唯一性的索引，数据库不能对它执行索引唯一扫描.
由于SQL返回LODGING列，而它并不存在于LODGING$MANAGER索引中，所以在索引范围查询后会执行一个通过ROWID访问表的操作.
WHERe子句中，如果索引列所对应的值的第一个字符由通配符(wildcard)开始，索引将不被采用.
SELECt LODGING FROM LODGING WHERe MANAGER LIKE '％HANMAN';
在这种情况下，ORACLE将使用全表扫描.
tiger:
oracle还支持索引的其他多种扫描方式,比如index skip scan,index full scan, index fast full scan; 细分的还有index full scan(min/max) ,index range scan(min/max),index xxx scan desc等.
基础表(Driving Table)是指被最先访问的表(通常以全表扫描的方式被访问). 根据优化器的不同，SQL语句中基础表的选择是不一样的.
如果你使用的是CBO (COST baseD OPTIMIZER)，优化器会检查SQL语句中的每个表的物理大小，索引的状态，然后选用花费最低的执行路径.
如果你用RBO (RULE baseD OPTIMIZER) ，并且所有的连接条件都有索引对应，在这种情况下，基础表就是FROM 子句中列在最后的那个表.举例：SELECt A.NAME ，B.MANAGER FROM WORKER A，LODGING B WHERe A.LODGING = B.LODING;由于LODGING表的LODING列上有一个索引，而且WORKER表中没有相比较的索引，WORKER表将被作为查询中的基础表.
tiger:
RBO对索引的选择是盲目的,不管索引是否高效, 都会优先选择索引,这也是RBO被淘汰的一个原因; 驱动表的选择不是选择小表, 而是选择小的结果集, 在多表关联中, 一般会选择带有过滤条件而且能过滤掉大部分记录的表做驱动表.
当SQL语句的执行路径可以使用分布在多个表上的多个索引时，ORACLE会同时使用多个索引并在运行时对它们的记录进行合并，检索出仅对全部索引有效的记录.
在ORACLE选择执行路径时，唯一性索引的等级高于非唯一性索引.
然而这个规则只有当WHERe子句中索引列和常量比较才有效.如果索引列和其它表的索引类相比较. 这种子句在优化器中的等级是非常低的.
如果不同表中两个相同等级的索引将被引用，FROM子句中表的顺序将决定哪个会被率先使用. FROM子句中最后的表的索引将有最高的优先级.
如果相同表中两个相同等级的索引将被引用，WHERe子句中最先被引用的索引将有最高的优先级.
举例： DEPTNO上有一个非唯一性索引，EMP_CAT也有一个非唯一性索引.
SELECt ENAME，FROM EMP WHERe DEPT_NO = 20 AND EMP_CAT = 'A';
这里，DEPTNO索引将被最先检索，然后同EMP_CAT索引检索出的记录进行合并. 执行路径如下：
TABLEACCESS BY ROWID ON EMP AND-EQUAL INDEX RANGE SCAN ON DEPT_IDX INDEX RANGE SCAN ON CAT_IDX tiger: 这是将近20年前低版本优化器在使用RBO时的表现; 现在的优化器,会根据表和索引上的统计信息,自动选择高效的索引.如果两个索引都是低效索引,才可能使用AND-EQUAL这样的执行计划.
当WHERe子句中有索引列，ORACLE不能合并它们，ORACLE将用范围比较.举例：DEPTNO上有一个非唯一性索引，EMP_CAT也有一个非唯一性索引.
SELECt ENAME FROM EMP WHERe DEPTNO> 20 AND EMP_CAT ='A';
这里只有EMP_CAT索引被用到，然后所有的记录将逐条与DEPTNO条件进行比较. 执行路径如下：
TABLE ACCESSBY ROWID ON EMP INDEX RANGESCAN ON CAT_IDX tiger: RBO的特性, 已经淘汰. 如果两个单字段索引的选择性都不好, 那么可以创建联合索引, 比如这个sql可以创建emp_cat和deptno的两字段联合索引.
30. 不明确的索引等级
当ORACLE无法判断索引的等级高低差别，优化器将只使用一个索引，它就是在WHERe子句中被列在最前面的.
举例：DEPTNO上有一个非唯一性索引，EMP_CAT也有一个非唯一性索引.
SELECt ENAM E FROM EMP WHERe DEPTNO > 20 AND EMP_CAT > 'A';
这里，ORACLE只用到了DEPT_NO索引.执行路径如下：
TABLEACCESS BY ROWID ON EMP INDEX RANGE SCAN ON DEPT_IDX
我们来试一下以下这种情况：
SQL>select index_name，uniqueness from user_indexes where table_name = 'EMP';
INDEX_NAME UNIQUENES---------------------------------------EMPNO UNIQUEEMPTYPE NONUNIQUE
SQL>select * from emp where empno >= 2 and emp_type = 'A' ;
no rows selected
ExecutionPlan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE 1 0 TABLE ACCESS (BY INDEX ROWID)OF 'EMP' 2 1 INDEX (RANGE SCAN) OF 'EMPTYPE' (NON-UNIQUE)
虽然EMPNO是唯一性索引，但是由于它所做的是范围比较，等级要比非唯一性索引的等式比较低.
tiger:
RBO的特性, 已经淘汰.
如果两个或以上索引具有相同的等级，你可以强制命令ORACLE优化器使用其中的一个(通过它，检索出的记录数量少) .举例：
SELECT ENAMEFROM EMPWHERe EMPNO = 7935AND DEPTNO + 0 = 10 AND EMP_TYPE || '' = 'A'
这是一种相当直接的提高查询效率的办法. 但是你必须谨慎考虑这种策略，一般来说，只有在你希望单独优化几个SQL时才能采用它.
这里有一个例子关于何时采用这种策略，假设在EMP表的EMP_TYPE列上有一个非唯一性的索引而EMP_CLASS上没有索引.
SELECt ENAME FROM EMP WHERe EMP_TYPE = 'A' AND EMP_CLASS = 'X';
优化器会注意到EMP_TYPE上的索引并使用它. 这是目前唯一的选择.
如果，一段时间以后，另一个非唯一性建立在EMP_CLASS上，优化器必须对两个索引进行选择，在通常情况下，优化器将使用两个索引并在他们的结果集合上执行排序及合并.
然而，如果其中一个索引（EMP_TYPE）接近于唯一性而另一个索引（EMP_CLASS）上有几千个重复的值.
排序及合并就会成为一种不必要的负担. 在这种情况下，你希望使优化器屏蔽掉EMP_CLASS索引.
用下面的方案就可以解决问题.
SELECt ENAME FROMEMP WHERe EMP_TYPE = 'A' AND EMP_CLASS||'' = 'X';
tiger:
用这种方法来强制索引失效是不建议的, 本人最近曾优化过一个9i库的sql, 涉及18张表关联的复杂SQL,里面包括外关联,not in,group by子查询等, 也是被上面方法做了"优化"修改了几处,导致最佳路径无法被选择. 经过分析,最后还是要把这几个禁用索引的地方改回正常,再通过指定表的关联顺序,得到最佳路径, 最终达到几倍的优化效果.
可以使用CBO可以用index相关hint 来指定或者禁用某个索引. RBO如果使用了index hint, 也变成了CBO.
WHERe子句中，如果索引列是函数的一部分．优化器将不使用索引而使用全表扫描．举例：低效：
SELECt … FROM DEPT WHERe SAL * 12 > 25000;
高效：
SELECt … FROM DEPT WHERe SAL > 25000/12;
这是一个非常实用的规则，请务必牢记
tiger:
这个说法是正确的,不管是不是索引列, 保持字段的独立,都是最好的选择. 很多初级程序员喜欢在日期字段上使用to_char, 也是非常非常不建议的.
如果表中有两个以上（包括两个）索引，其中有一个唯一性索引，而其它是非唯一性．
在这种情况下，ORACLE将使用唯一性索引而完全忽略非唯一性索引．举例：
SELECt ENAME FROM EMP WHERe EMPNO = 2326 AND DEPTNO = 20 ;
这里，只有EMPNO上的索引是唯一性的，所以EMPNO索引将用来检索记录．
TABLEACCESS BY ROWID ON EMP INDEX UNIQUE SCAN ON EMP_NO_IDX
通常，我们要避免在索引列上使用NOT，NOT会产生在和在索引列上使用函数相同的影响.
当ORACLE 遇到“NOT”，就会停止使用索引转而执行全表扫描.
当使用“<>”时oracle也不会使用索引而执行全表扫描，而使用“< 列值 or >列值”的形式会执行两次索引扫描，建议采用 “列名<列值 union select 列名 > 列值”的形式，速度更快.
举例：
低效：(这里，不使用索引)
SELECT … FROM DEPT WHERe NOT DEPT_CODE = 0
高效：(这里，使用了索引)
SELECt … FROM DEPT WHERe DEPT_CODE > 0;
需要注意的是，在某些时候，ORACLE优化器会自动将NOT转化成相对应的关系操作符.
NOT > to <= NOT >= to < NOT < to >= NOT <= to >
tiger:
这个说法部分是正确的, != , <> , not in (1,2,3) , not like , like '%xxx%',这些写法都是无法使用索引的;
但是<> 的等价改写不能用union ,而是union all.
通常情况下，用UNIOn替换WHERe子句中的OR将会起到较好的效果. 对索引列使用OR将造成全表扫描.
注意，以上规则只针对多个索引列有效. 如果有column没有被索引，查询效率可能会因为你没有选择OR而降低. 在下面的例子中，LOC_ID 和REGION上都建有索引.
高效：
SELECtLOC_ID ，LOC_DESC ，REGION FROM LOCATION WHERe LOC_ID = 10 UNIOn SELECt LOC_ID ，LOC_DESC ，REGION FROM LOCATION WHERe REGION = "MELBOURNE"
低效：
SELECt LOC_ID ，LOC_DESC ，REGION FROM LOCATION WHERe LOC_ID = 10 OR REGION = "MELBOURNE"
如果你坚持要用OR，那就需要返回记录最少的索引列写在最前面.注意：
WHEReKEY1 = 10 (返回最少记录)ORKEY2 = 20 (返回最多记录)ORACLE内部将以上转换为WHEReKEY1 = 10 AND((NOTKEY1 = 10) AND KEY2 = 20)
下面的测试数据仅供参考：(a = 1003 返回一条记录 ，b = 1 返回1003条记录)
SQL>select * from unionvsor 2 where a = 1003 or b = 1;1003rows selected.ExecutionPlan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE 1 0 ConCATENATION 2 1 TABLE ACCESS (BY INDEXROWID) OF 'UNIOnVSOR' 3 2 INDEX (RANGE SCAN) OF 'UB'(NON-UNIQUE) 4 1 TABLE ACCESS (BY INDEXROWID) OF 'UNIOnVSOR' 5 4 INDEX (RANGE SCAN) OF 'UA'(NON-UNIQUE)Statistics---------------------------------------------------------- 0 recursive calls 0 db block gets 144 consistent gets 0 physical reads 0 redo size 63749 bytes sent via SQL*Net to client 7751 bytes received via SQL*Net from client 68 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1003 rows processedSQL>select * from unionvsor 2 where b = 1 or a = 1003 ;1003rows selected.ExecutionPlan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE 1 0 ConCATENATION 2 1 TABLE ACCESS (BY INDEXROWID) OF 'UNIOnVSOR' 3 2 INDEX (RANGE SCAN) OF 'UA'(NON-UNIQUE) 4 1 TABLE ACCESS (BY INDEXROWID) OF 'UNIOnVSOR' 5 4 INDEX (RANGE SCAN) OF 'UB'(NON-UNIQUE)Statistics---------------------------------------------------------- 0 recursive calls 0 dbblock gets 143 consistent gets 0 physical reads 0 redo size 63749 bytes sent via SQL*Net to client 7751 bytes received via SQL*Net from client 68 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1003 rows processedSQL>select * from unionvsor 2 where a = 1003 3 union 4 select * from unionvsor 5 where b = 1;1003rows selected.ExecutionPlan---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE 1 0 SORT (UNIQUE) 2 1 UNIOn-ALL 3 2 TABLE ACCESS (BY INDEXROWID) OF 'UNIOnVSOR' 4 3 INDEX (RANGE SCAN) OF'UA' (NON-UNIQUE) 5 2 TABLE ACCESS (BY INDEX ROWID) OF 'UNIOnVSOR' 6 5 INDEX (RANGE SCAN) OF'UB' (NON-UNIQUE)Statistics---------------------------------------------------------- 0 recursive calls 0 db block gets 10 consistent gets 0 physical reads 0 redo size 63735 bytes sent via SQL*Net to client 7751 bytes received via SQL*Net from client 68 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 1003 rows processed
用UNIOn的效果可以从consistent gets和 SQL*NET的数据交换量的减少看出
tiger :
用union 改写or 不但不等价,而且可能更低效. 结果集相同只是特例,我在我的很多篇公众号文章里面都有提到.
上面test case,用union 改写后,buffer gets从144到10, 这个数据是不科学的, union 还多了一步排序, 效率应该比原SQL写法更低才符合预期.
下面的查询可以被更有效率的语句替换：
低效：
SELECt ….FROM LOCATIONWHERe LOC_ID = 10 OR LOC_ID = 20 OR LOC_ID = 30
高效
SELECt …FROM LOCATION WHERe LOC_IN IN (10，20，30);
这是一条简单易记的规则，但是实际的执行效果还须检验，在ORACLE8i下，两者的执行路径似乎是相同的．
tiger:
既然已经看到了执行计划相同,就不用再怀疑了, 二者就是等价的, 只不过in的写法更简洁而已.
避免在索引中使用任何可以为空的列，ORACLE将无法使用该索引 ．
对于单列索引，如果列包含空值，索引中将不存在此记录.
对于复合索引，如果每个列都为空，索引中同样不存在此记录. 如果至少有一个列不为空，则记录存在于索引中．
举例：如果唯一性索引建立在表的A列和B列上，并且表中存在一条记录的A，B值为(123，null) ，ORACLE将不接受下一条具有相同A，B值（123，null）的记录(插入).
然而如果所有的索引列都为空，ORACLE将认为整个键值为空,而空不等于空. 因此你可以插入1000条具有相同键值的记录，
当然它们都是空!因为空值不存在于索引列中，所以WHERe子句中对索引列进行空值比较将使ORACLE停用该索引.
举例：
低效：(索引失效)
SELECt … FROM DEPARTMENT WHERe DEPT_CODE IS NOT NULL;
高效：(索引有效)
SELECt … FROM DEPARTMENT WHERe DEPT_CODE >=0; tiger: 上面两个sql的写法, 在9i版本可能不同; 在10g及以上版本, 二者的执行计划都是一样的,没有改写的必要.
如果索引是建立在多个列上，
只有在它的第一个列(leading column)被where子句引用时，优化器才会选择使用该索引. 这也是一条简单而重要的规则. 见以下实例.
SQL>create table multiindexusage ( inda number ，indb number ，descr varchar2(10));Tablecreated.SQL>create index multindex on multiindexusage(inda，indb);Indexcreated.SQL>set autotrace traceonlySQL> select * from multiindexusage where inda = 1;ExecutionPlan---------------------------------------------------------- 0 SELECt STATEMENT Optimizer=CHOOSE 1 0 TABLE ACCESS (BY INDEX ROWID)OF 'MULTIINDEXUSAGE' 2 1 INDEX (RANGE SCAN) OF'MULTINDEX' (NON-UNIQUE)
SQL>select * from multiindexusage where indb= 1;ExecutionPlan---------------------------------------------------------- 0 SELECt STATEMENT Optimizer=CHOOSE 1 0 TABLE ACCESS (FULL) OF'MULTIINDEXUSAGE'
很明显，当仅引用索引的第二个列时，优化器使用了全表扫描而忽略了索引
tiger:
如果第一个列的唯一值比较少, 还可以使用index skip
scan.
当执行查询时，ORACLE采用了内部的操作. 下表显示了几种重要的内部操作.
ORACLE Clause 内部操作ORDER BY SORT ORDER BYUNIOn UNIOn-ALLMINUS MINUSINTERSECT INTERSECTDISTINCT，MINUS，INTERSECT，UNIOnSORT UNIQUEMIN，MAX，COUNT SORT AGGREGATEGROUP BY SORT GROUP BYROWNUM COUNT or COUNT STOPKEYQueries involving Joins SORT JOIN，MERGE JOIN，NESTED LOOPSConNECT BY ConNECT BY
当SQL语句需要UNIOn两个查询结果集合时，这两个结果集合会以UNIOn-ALL的方式被合并，然后在输出最终结果前进行排序.
如果用UNIOn ALL替代UNIOn，这样排序就不是必要了. 效率就会因此得到提高.
举例： 低效：
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';
需要注意的是，UNIOn ALL 将重复输出两个结果集合中相同记录. 因此各位还是要从业务需求分析使用UNIOn ALL的可行性.
UNIOn 将对结果集合排序，这个操作会使用到SORT_AREA_SIZE这块内存. 对于这块内存的优化也是相当重要的. 下面的SQL可以用来查询排序的消耗量
Select substr(name,1,25) "Sort Area Name",substr(value,1,15)"Value" from v$sysstat where name like 'sort%' tiger:
两个完全一样的sql做union /union all, 这个test case选的有些奇怪. union all是简单的将两个结果集合并; 而union 是合并后的结果集再去重,逻辑是完全不同的.
对于表的访问，可以使用两种Hints.FULL和 ROWID
FULLhint 告诉ORACLE使用全表扫描的方式访问指定表.例如：
SELECt * FROM EMP WHERe EMPNO = 7893;
ROWIDhint 告诉ORACLE使用TABLE ACCESS BY ROWID的操作访问表.通常，你需要采用TABLE ACCESS BY ROWID的方式特别是当访问大表的时候，使用这种方式，你需要知道ROIWD的值或者使用索引.
如果一个大表没有被设定为缓存(CACHED)表而你希望它的数据在查询结束是仍然停留在SGA中，
你就可以使用CACHE hint 来告诉优化器把资料保留在SGA中. 通常CACHE hint 和 FULL hint 一起使用.
例如：
SELECt *FROMWORK;
索引hint 告诉ORACLE使用基于索引的扫描方式. 你不必说明具体的索引名称例如：
SELECt LODGING FROM LODGING WHERe MANAGER = 'BILL GATES';
在不使用hint的情况下，以上的查询应该也会使用索引，然而，如果该索引的重复值过多而你的优化器是CBO，优化器就可能忽略索引.
在这种情况下，你可以用INDEX hint强制ORACLE使用该索引.
ORACLE hints 还包括ALL_ROWS，FIRST_ROWS，RULE，USE_NL，USE_MERGE，USE_HASH 等等.
使用hint，表示我们对ORACLE优化器缺省执行路径不满意，需要手工修改.
这是一个很有技巧性的工作. 建议只针对特定的，少数的SQL进行hint的优化.对ORACLE的优化器还是要有信心(特别是CBO)
ORDER BY 子句只在两种严格的条件下使用索引.ORDER BY中所有的列必须包含在相同的索引中并保持在索引中的排列顺序.ORDER BY中所有的列必须定义为非空.WHERe子句使用的索引和ORDER BY子句中所使用的索引不能并列.
例如： 表DEPT包含以下列：
DEPT_CODE PK NOT NULL DEPT_DESC NOT NULL DEPT_TYPE NULL
非唯一性的索引(DEPT_TYPE) 低效：(索引不被使用)
SELECtDEPT_CODE FROM DEPT ORDER BY DEPT_TYPE; EXPLAIN PLAN： SORT ORDER BY TABLE ACCESS FULL
高效：(使用索引)
SELECt DEPT_CODE FROM DEPT WHERe DEPT_TYPE > 0; EXPLAIN PLAN： TABLE ACCESS BY ROWID ON EMP INDEX RANGE SCAN ON DEPT_IDX
ORDER BY 也能使用索引! 这的确是个容易被忽视的知识点. 我们来验证一下：
SQL> select * from emp order by empno;ExecutionPlan--------------------------------------------------------- 0 SELECt STATEMENT Optimizer=CHOOSE 1 0 TABLE ACCESS (BY INDEX ROWID)OF 'EMP' 2 1 INDEX (FULL SCAN) OF 'EMPNO'(UNIQUE) tiger:
两个逻辑不同的SQL没有可比性,order by能使用索引是基本常识. 最后一个sql能使用索引, 那是因为empno的字段定义为not null.
当比较不同数据类型的数据时，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会优先转换数值类型到字符类型
tiger:
上面的例子写对了,最后的总结写反了, 应该是优先转换字符串类型到数值类型;
这里只列举了一种隐式类型转换形式, 常见的还有date与timestamp, char与nchar,raw与字符串等.
某些SELECt 语句中的WHERe子句不使用索引. 这里有一些例子.在下面的例子里，'!=' 将不使用索引.
记住，索引只能告诉你什么存在于表中，而不能告诉你什么不存在于表中https://cloud.tencent.com/developer/article//经典^_^不使用索引：
SELECT ACCOUNT_NAME FROM TRANSACTION WHERe AMOUNT !=0;
使用索引：
SELECt ACCOUNT_NAMEFROM TRANSACTIONWHERe AMOUNT >0; tiger:
这个改写高效的前提是
1.amount 没有负值
2.amount>0 对应的记录比较少
如果没有上面前提,改写是没有意义的
下面的例子中，'||'是字符连接函数. 就象其它函数那样，停用了索引.不使用索引：
SELECt ACCOUNT_NAME，AMOUNTFROM TRANSACTIONWHERe ACCOUNT_NAME||ACCOUNT_TYPE='AMEXA';
使用索引：
SELECt ACCOUNT_NAME，AMOUNTFROM TRANSACTIONWHERe ACCOUNT_NAME = 'AMEX'AND ACCOUNT_TYPE=' A'; tiger: 第31/32条的实例
下面的例子中，'+'是数学函数. 就象其它数学函数那样，停用了索引.不使用索引：
SELECt ACCOUNT_NAME，AMOUNTFROM TRANSACTIONWHERe AMOUNT + 3000 >5000;
使用索引：
SELECt ACCOUNT_NAME，AMOUNTFROM TRANSACTIONWHERe AMOUNT > 2000 ; tiger: 第31/32条的实例
下面的例子中，相同的索引列不能互相比较，这将会启用全表扫描.不使用索引：
SELECt ACCOUNT_NAME，AMOUNTFROM TRANSACTIONWHERe ACCOUNT_NAME = NVL(：ACC_NAME，ACCOUNT_NAME);
使用索引：
SELECt ACCOUNT_NAME，AMOUNTFROM TRANSACTIONWHERe ACCOUNT_NAME LIKE NVL(：ACC_NAME，'%');
如果一定要对使用函数的列启用索引，ORACLE新的功能：
基于函数的索引(Function-based Index) 也许是一个较好的方案.
CREATE INDEX EMP_I ON EMP(UPPER(ename)); SELECt * FROM emp WHERe UPPER(ename) ='BLACKSNAIL';
如果你对一个列和一组有限的值进行比较，优化器可能执行多次扫描并对结果进行合并连接.举例：SELECt * FROM LODGING WHERe MANAGER IN ('BILL GATES'，'KEN MULLER'); 优化器可能将它转换成以下形式
SELECt * FROM LODGING WHERe MANAGER = 'BILL GATES' OR MANAGER = 'KEN MULLER';
当选择执行路径时，优化器可能对每个条件采用LODGING$MANAGER上的索引范围扫描.
返回的ROWID用来访问LODGING表的记录(通过TABLE ACCESS BY ROWID 的方式). 最后两组记录以连接(concatenation)的形式被组合成一个单一的集合.
ExplainPlan ：
SELECt STATEMENT Optimizer=CHOOSE
ConCATENATION
TABLEACCESS (BY INDEX ROWID) OF LODGING
INDEX(RANGE SCAN ) OF LODGING$MANAGER (NON-UNIQUE)
TABLEACCESS (BY INDEX ROWID) OF LODGING
INDEX(RANGE SCAN ) OF LODGING$MANAGER (NON-UNIQUE)
tiger:
这个转换是优化器自动完成, 程序员不需要考虑用in还是用or. 10g及以上版本的执行计划已经不是CONCATENATION, 而是inlist iterator.
基于成本的优化器(CBO，Cost-based Optimizer)对索引的选择性进行判断来决定索引的使用是否能提高效率.
如果索引有很高的选择性，那就是说对于每个不重复的索引键值，只对应数量很少的记录.
比如，表中共有100条记录而其中有80个不重复的索引键值. 这个索引的选择性就是80/100 = 0.8 . 选择性越高，通过索引键值检索出的记录就越少.
如果索引的选择性很低，检索数据就需要大量的索引范围查询操作和ROWID 访问表的操作. 也许会比全表扫描的效率更低.
下列经验请参阅：
a.如果检索数据量超过30%的表中记录数.使用索引将没有显着的效率提高
b.在特定情况下，使用索引也许会比全表扫描慢，但这是同一个数量级上的区别. 而通常情况下，使用索引比全表扫描要快几倍乃至几千倍!
tiger:
30%这个比例是非常高的,差不多一个字段有3个不同的值,在平均分布的情况下,就能使用索引,实际上这样的索引效率是非常低的, 比全表扫描效率要低. 这样的索引, 如果使用CBO, 根本就不会被使用, 相当于创建了一个无用的索引, 占用空间,影响dml效率.
带有DISTINCT，UNIOn，MINUS，INTERSECT，ORDER BY的SQL语句会启动SQL引擎执行耗费资源的排序(SORT)功能.
DISTINCT需要一次排序操作，而其它的至少需要执行两次排序.
例如，一个UNIOn查询，其中每个查询都带有GROUP BY子句，
GROUP BY会触发嵌入排序(NESTED SORT) ;
这样，每个查询需要执行一次排序，然后在执行UNIOn时，又一个唯一排序(SORT UNIQUE)操作被执行而且它只能在前面的嵌入排序结束后才能开始执行. 嵌入的排序的深度会大大影响查询的效率.
通常，带有UNIOn，MINUS ，INTERSECT的SQL语句都可以用其它方式重写.
如果你的数据库的SORT_AREA_SIZE调配得好，使用UNIOn，MINUS，INTERSElECT也是可以考虑的，毕竟它们的可读性很强.
tiger:
union 和 distinct是一样的,改写没有意义; minus和intersect 都建议使用表关联来改写,效率更高.
提高GROUP BY 语句的效率，可以通过将不需要的记录在GROUP BY 之前过滤掉.下面两个查询返回相同结果但第二个明显就快了许多.低效：
SELECT JOB ，AVG(SAL) FROM EMP GROUP JOB HAVINg JOB = 'PRESIDENT' OR JOB = 'MANAGER';
高效：
SELECt JOB ，AVG(SAL) FROM EMP WHERe JOB = 'PRESIDENT' OR JOB = 'MANAGER' GROUP JOB; tiger:
与第14条重复了
49. 使用显式的光标(CURSORs)
使用隐式的光标，将会执行两次操作.
第一次检索记录，
第二次检查TOO MANY ROWS 这个exception .
而显式光标不执行第二次操作.
tiger:
有人做过测试, 隐式游标 for cur in (select .... from xxx ) 的写法,代码简洁,效率也比显式游标要高.当然,使用显示游标还有其他的一些好处, 不能一概而论.
使用较大的BUFFER(比如10MB )
可以提高EXPORT和import的速度.ORACLE将尽可能地获取你所指定的内存大小，即使在内存不满足，也不会报错.这个值至少要和表中最大的列相当，否则列值会被截断.
总是将你的表和索引建立在不同的表空间内(TABLESPACES). 决不要将不属于ORACLE内部系统的对象存放到SYSTEM表空间里. 同时，确保数据表空间和索引表空间置于不同的硬盘上.
tiger:
索引和表分别存放不同的表空间是一个好习惯, 因为9i没有asm,10g及以上版本有了asm, 在性能上没有明确要求表和索引分别存放不同的表空间, 在管理上会有一些好处.
总结:
SQL优化是一个比较严谨的事情, 一些未经证实或者有明显错误的小"技巧"在网上广泛流传,不是一件好事情. 希望喜欢分享的专家们,在出版专业书籍,写博客或是公众号文章时, 也能本着严肃认真的态度,不要误导一些不明真相的群众.
我的点评也是一家之言,欢迎大家一起讨论,批评指正!