ORACLE SQL性能优化

• 共享SQL语句

    为了不重复解析相同的SQL语句,在第一次解析之后, ORACLE将SQL语句存放在内存中.这块位于系统全局区域SGA(system global area)的共享池(shared buffer pool)中的内存可以被所有的数据库用户共享. 因此,当你执行一个SQL语句(有时被称为一个游标)时,如果它和之前的执行过的语句完全相同, ORACLE就能很快获得已经被解析的语句以及最好的执行路径. ORACLE的这个功能大大地提高了SQL的执行性能并节省了内存的使用.这个功能并不适用于多表连接查询.当前被执行的语句和共享池中的语句必须完全相同才会使用此功能。 例如:SELECT * FROM EMP; SELECT * from EMP; Select * From Emp;   SELECT      *     FROM EMP;

这个几个语句都不一样，ORACLE会重新解析。

• 选择最有效率的表名顺序(只在基于规则的优化器中有效)

ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,因此FROM子句中写在最后的表(基础表 driving table)将被最先处理. 在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.当ORACLE处理多个表时, 会运用排序及合并的方式连接它们.首先,扫描第一个表(FROM子句中最后的那个表)并对记录进行排序,然后扫描第二个表(FROM子句中最后第二个表),最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并.

例如:

     表 TAB1 16,384 条记录

     表 TAB2 1 条记录

     选择TAB2作为基础表 (最好的方法)

     select count(*) from tab1,tab2   执行时间0.96秒

     选择TAB2作为基础表 (不佳的方法)

     select count(*) from tab2,tab1   执行时间26.09秒

如果有3个以上的表连接查询, 那就需要选择交叉表(intersection 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

• WHERE子句中的连接顺序

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’;

• SELECT子句中避免使用“*”

  当你想在SELECT子句中列出所有的COLUMN时,使用动态SQL列引用 ‘*’ 是一个方便的方法.不幸的是,这是一个非常低效的方法. 实际上,ORACLE在解析的过程中, 会将’*’ 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间.

• 全表删除时用TRUNCATE替代DELETE

        当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) 用来存放可以被恢复的信息. 如果你没有COMMIT事务,ORACLE会将数据恢复到删除之前的状态(准确地说是恢复到执行删除命令之前的状况)。        而当运用TRUNCATE时, 回滚段不再存放任何可被恢复的信息.当命令运行后,数据不能被恢复.因此很少的资源被调用,执行时间也会很短.

• 用Where子句替换HAVING子句

    避免使用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 H.EMPNO, E.ENAME, H.HIST_TYPE, T.TYPE_DESC, COUNT (*)
     FROM HISTORY_TYPE T, EMP E, EMP_HISTORY H
     WHERE H.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 VARCHAR2
AS
    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 VARCHAR2
AS
   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;

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;

• 多表查询使用表的别名(Alias)

• 用EXISTS（NOT EXITS）替代IN(NOT IN)

--低效:
SELECT * FROM EMP (基础表) WHERE EMPNO > 0  AND DEPTNO IN (SELECT DEPTNO FROM DEPT WHERE LOC = ‘MELB’)
--高效:
SELECT * FROM EMP (基础表) WHERE EMPNO > 0  AND EXISTS (SELECT ‘X’  FROM DEPT  WHERE DEPT.DEPTNO = EMP.DEPTNO  AND LOC = ‘MELB’)

 (注: 相对来说,用NOT EXISTS替换NOT IN 将更显著地提高效率)

• 用EXISTS替换DISTINCT

--低效: 
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核心模块将在子查询的条件一旦满足后,立刻返回结果. 

          

         

转载于:https://my.oschina.net/jianxiao/blog/277668