oracle中性能代码

识别‘低效执行’的 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;

 

27.       基础表的选择     基础表（ 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 表将被作为查询中的基础表。

 

28.       多个平等的索引
　当 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 索引检索出的记录进行合并。 执行路径如下：
    TABLE ACCESS BY ROWID ON EMP
　　 AND-EQUAL
　　　 INDEX RANGE SCAN ON DEPT_IDX
　　　 INDEX RANGE SCAN ON CAT_IDX

强制索引失效
    如果两个或以上索引具有相同的等级，你可以强制命令 ORACLE 优化器使用其中的一个（通过它，检索出的记录数量少） .
    举例：
    SELECT ENAME
　 FROM EMP
　 WHERE EMPNO = 7935

 

 

 

1. 选用适合的 ORACLE 优化器
        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 优化器，而直接采用基于规则或者基于成本的优化器。
    2.       访问 Table 的方式 ORACLE 采用两种访问表中记录的方式：
    a.       全表扫描
         全表扫描就是顺序地访问表中每条记录。 ORACLE 采用一次读入多个数据块（ database block ）的方式优化全表扫描。
    b.       通过 ROWID 访问表
         你可以采用基于 ROWID 的访问方式情况，提高访问表的效率， ROWID 包含了表中记录的物理位置信息…… ORACLE 采用索引（ INDEX ）实现了数据和存放数据的物理位置（ ROWID ）之间的联系。 通常索引提供了快速访问 ROWID 的方法，因此那些基于索引列的查询就可以得到性能上的提高。
    3.       共享 SQL 语句
    为了不重复解析相同的 SQL 语句，在第一次解析之后， ORACLE 将 SQL 语句存放在内存中。这块位于系统全局区域 SGA （ system global area ）的共享池（ 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.       两个语句所指的对象必须完全相同：
    例如：
    用户       对象名             如何访问
    Jack       sal_limit          private synonym
　　　　 Work_city      public synonym
　　　　 Plant_detail     public synonym
　 Jill         sal_limit          private synonym
　　　　 Work_city      public synonym
　　　　 Plant_detail     table owner
　考虑一下下列 SQL 语句能否在这两个用户之间共享。

SQL	能否共享	原因
select max(sal_cap) from sal_limit;	不能	每个用户都有一个 private synonym - sal_limit , 它们是不同的对象
select count(*0 from work_city where sdesc like 'NEW%';	能	两个用户访问相同的对象 public synonym - work_city
select a.sdesc,b.location from work_city a , plant_detail b where a.city_id = b.city_id	不能	用户 jack 通过 private synonym 访问 plant_detail 而 jill 是表的所有者 , 对象不同 .

 

    C.      

两个 SQL 语句中必须使用相同的名字的绑定变量（ bind variables ）
    例如：第一组的两个 SQL 语句是相同的（可以共享），而第二组中的两个语句是不同的（即使在运行时，赋于不同的绑定变量相同的值）
    a.
　 select pin ， name from people where pin = ： blk1.pin ；
　 select pin ， name from people where pin = ： blk1.pin ；
　 b.
　 select pin ， name from people where pin = ： blk1.ot_ind ；
　 select pin ， name from people where pin = ： blk1.ov_ind ；
　 4. 选择最有效率的表名顺序（只在基于规则的优化器中有效）
    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

 

 

7.      减少访问数据库的次数
　当执行每条 SQL 语句时， ORACLE 在内部执行了许多工作： 解析 SQL 语句， 估算索引的利用率， 绑定变量 ， 读数据块等等。 由此可见， 减少访问数据库的次数 ， 就能实际上减少 ORACLE 的工作量。
    例如，以下有三种方法可以检索出雇员号等于 0342 或 0291 的职员。
    方法 1 （最低效）
    SELECT EMP_NAME , SALARY , GRADE
    FROM EMP
    WHERE EMP_NO = 342;
     SELECT EMP_NAME , SALARY , GRADE
    FROM EMP
    WHERE EMP_NO = 291;
方法 2 （次低效）
       DECLARE
        CURSOR C1 (E_NO NUMBER) IS
        SELECT EMP_NAME,SALARY,GRADE
        FROM EMP
        WHERE EMP_NO = E_NO;
    BEGIN
        OPEN C1(342);
        FETCH C1 INTO …,..,.. ;
                OPEN C1(291);
       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.
　 8.       使用 DECODE 函数来减少处理时间
　使用 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_SAL
FROM EMP WHERE ENAME LIKE ‘SMITH%’;
　类似的， DECODE 函数也可以运用于 GROUP BY 和 ORDER BY 子句中。
    9.       整合简单，无关联的数据库访问
　如果你有几个简单的数据库查询语句，你可以把它们整合到一个查询中（即使它们之间没有关系）
    例如：
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
FROM CAT 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’;
（译者按： 虽然采取这种方法，效率得到提高，但是程序的可读性大大降低，所以读者还是要权衡之间的利弊）

 

17.       使用表的别名（ Alias ）     当在 SQL 语句中连接多个表时， 请使用表的别名并把别名前缀于每个 Column 上。这样一来，就可以减少解析的时间并减少那些由 Column 歧义引起的语法错误。
    （译者注： Column 歧义指的是由于 SQL 中不同的表具有相同的 Column 名，当 SQL 语句中出现这个 Column 时， SQL 解析器无法判断这个 Column 的归属）
    18.       用 EXISTS 替代 IN
　在许多基于基础表的查询中，为了满足一个条件，往往需要对另一个表进行联接。在这种情况下， 使用 EXISTS （或 NOT EXISTS ）通常将提高查询的效率。
    低效：
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 将更显著地提高效率，下一节中将指出）
    19.       用 NOT EXISTS 替代 NOT IN
　在子查询中， 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 B
WHERE A.DEPT_NO = B.DEPT(+)
AND B.DEPT_NO IS NULL
AND B.DEPT_CAT(+) = ‘A’
　（方法二： 最高效）
SELECT ….
FROM EMP E
WHERE NOT EXISTS (SELECT ‘X’
                    FROM DEPT D
                    WHERE D.DEPT_NO = E.DEPT_NO
                    AND DEPT_CAT = ‘A’);
　 20.       用表连接替换 EXISTS
　通常来说 ， 采用表连接的方式比 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’ ;
　（译者按： 在 RBO 的情况下，前者的执行路径包括 FILTER ，后者使用 NESTED LOOP ）
    21.       用 EXISTS 替换 DISTINCT
　当提交一个包含一对多表信息（比如部门表和雇员表）的查询时，避免在 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 核心模块将在子查询的条件一旦满足后，立刻返回结果。

 

 

分离表和索引
　总是将你的表和索引建立在不同的表空间内（ TABLESPACES ）。 决不要将不属于 ORACLE 内部系统的对象存放到 SYSTEM 表空间里。 同时，确保数据表空间和索引表空间置于不同的硬盘上。
    译者按：“同时，确保数据表空间和索引表空间置与不同的硬盘上。”可能改为如下更为准确 “同时，确保数据表空间和索引表空间置与不同的硬盘控制卡控制的硬盘上。”

 

优化 EXPORT 和 IMPORT
　使用较大的 BUFFER （比如 10MB ， 10 ， 240 ， 000 ）可以提高 EXPORT 和 IMPORT 的速度。

 

使用显式的游标（ CURSORs ）
    使用隐式的游标，将会执行两次操作。 第一次检索记录， 第二次检查 TOO MANY ROWS 这个 exception . 而显式游标不执行第二次操作。

 

 

避免使用耗费资源的操作
　带有 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 ， INTERSECT 也是可以考虑的， 毕竟它们的可读性很强

 

　 AND DEPTNO + 0 = 10    /*DEPTNO 上的索引将失效 */
　 AND EMP_TYPE || ‘’ = ‘ A ’   /*EMP_TYPE 上的索引将失效 */

 

 

避免在索引列上使用 NOT
　通常，我们要避免在索引列上使用 NOT ， NOT 会产生在和在索引列上使用函数相同的影响。 当 ORACLE “遇到” NOT ，他就会停止使用索引转而执行全表扫描。
    举例：
    低效： （这里，不使用索引）
    SELECT …
    FROM DEPT
　 WHERE DEPT_CODE NOT = 0 ；
    高效： （这里，使用了索引）
    SELECT …
    FROM DEPT
　 WHERE DEPT_CODE > 0 ；
    需要注意的是，在某些时候， ORACLE 优化器会自动将 NOT 转化成相对应的关系操作符。
    NOT > to <=
　 NOT >= to <
　 NOT < to >=
　 NOT <= to >
    译者按：在这个例子中，作者犯了一些错误。 例子中的低效率 SQL 是不能被执行的。
    我做了一些测试：
    SQL> select * from emp where NOT empno > 1 ；
　 no rows selected
　 Execution Plan
　 ----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=CHOOSE
　 1    0   TABLE ACCESS （ BY INDEX ROWID ） OF 'EMP'
　 2    1     INDEX （ RANGE SCAN ） OF 'EMPNO' （ UNIQUE ）
    SQL> select * from emp where empno <= 1 ；
　 no rows selected
　 Execution Plan
　 ----------------------------------------------------------
    0      SELECT STATEMENT Optimizer=CHOOSE
　 1    0   TABLE ACCESS （ BY INDEX ROWID ） OF 'EMP'
　 2    1     INDEX （ RANGE SCAN ） OF 'EMPNO' （ UNIQUE ）
    两者的效率完全一样，也许这符合作者关于“ 在某些时候， ORACLE 优化器会自动将 NOT 转化成相对应的关系操作符” 的观点。
    35.       用 >= 替代 >
    如果 DEPTNO 上有一个索引，
    高效：
    SELECT *
　 FROM EMP
　 WHERE DEPTNO >=4
    低效：
    SELECT *
　 FROM EMP
　 WHERE DEPTNO >3
    两者的区别在于， 前者 DBMS 将直接跳到第一个 DEPT 等于 4 的记录而后者将首先定

 

一.SQL语言的使用
1.IN 操作符
    用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。
    但是用IN的SQL性能总是比较低的，从ORACLE执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别：
    ORACLE试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。
    由此可见用IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。

    推荐方案：在业务密集的SQL当中尽量不采用IN操作符
2.NOT IN操作符
    此操作是强列推荐不使用的，因为它不能应用表的索引。

    推荐方案：用NOT EXISTS 或（外连接+判断为空）方案代替
3.<> 操作符（不等于）
    不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。

    推荐方案：用其它相同功能的操作运算代替，如
    a<>0 改为 a>0 or a<0
    a<>'' 改为 a>''
4.IS NULL 或IS NOT NULL操作（判断字段是否为空）
    判断字段是否为空一般是不会应用索引的，因为B树索引是不索引空值的。

    推荐方案：
    用其它相同功能的操作运算代替，如
    a is not null 改为 a>0 或a>''等。
    不允许字段为空，而用一个缺省值代替空值，如业扩申请中状态字段不允许为空，缺省为申请。
    建立位图索引（有分区的表不能建，位图索引比较难控制，如字段值太多索引会使性能下降，多人更新操作会增加数据块锁的现象）
5.>及<操作符(大于或小于操作符)
    大于或小于操作符一般情况下是不用调整的，因为它有索引就会采用索引查找，但有的情况下可以对它进行优化，
    如一个表有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的记录索引。
6.LIKE操作符
    LIKE操作符可以应用通配符查询，里面的通配符组合可能达到几乎是任意的查询，但是如果用得不好则会产生性能上的问题，
    如LIKE '%5400%' 这种查询不会引用索引，而LIKE 'X5400%'则会引用范围索引。
    一个实际例子：
    用YW_YHJBQK表中营业编号后面的户标识号可来查询营业编号 YY_BH LIKE '%5400%' 这个条件会产生全表扫描，
    如果改成YY_BH LIKE 'X5400%' OR YY_BH LIKE 'B5400%' 则会利用YY_BH的索引进行两个范围的查询，性能肯定大大提高。
7.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
 8.大量数据时不用upper()和lower

二.SQL书写的影响

1.同一功能同一性能不同写法SQL的影响(使用ORACLE的共享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的执行频率。

2.WHERE后面的条件顺序影响
    a.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占用率明显比第一条低
    b.查询表顺序的影响
    在FROM后面的表中的列表顺序会对SQL执行性能影响，在没有索引及ORACLE没有对表进行统计分析的情况下ORACLE会按表出现的顺序进行链接，
    由此因为表的顺序不对会产生十分耗服务器资源的数据交叉。（注：如果对表进行了统计分析，ORACLE会自动先进小表的链接，再进行大表的链接）

三.SQL语句索引的利用

    1.对操作符的优化（见上节）
    2.对条件字段的一些优化:
    a.采用函数处理的字段不能利用索引，如：
     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)
    b.进行了显式或隐式的运算的字段不能进行索引，如：
     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字段是字符型。
    c.条件内包括了多个本表的字段运算时不能进行索引，如：
     ys_df>cx_df，无法进行优化
     qc_bh||kh_bh='5400250000'，优化处理：qc_bh='5400' and kh_bh='250000'
四.应用ORACLE的HINT（提示）处理:提示处理是在ORACLE产生的SQL分析执行路径不满意的情况下要用到的。它可以对SQL进行以下方面的提示
    1.目标方面的提示：
     COST（按成本优化）
     RULE（按规则优化）
     CHOOSE（缺省）（ORACLE自动选择成本或规则进行优化）
     ALL_ROWS（所有的行尽快返回）
     FIRST_ROWS（第一行数据尽快返回）
    2.执行方法的提示：
     USE_NL（使用NESTED LOOPS方式联合）
     USE_MERGE（使用MERGE JOIN方式联合）
     USE_HASH（使用HASH JOIN方式联合）
    3.索引提示：
 INDEX（TABLE INDEX）（使用提示的表索引进行查询）
    4.其它高级提示（如并行处理等等）
    ORACLE的提示功能是比较强的功能，也是比较复杂的应用，并且提示只是给ORACLE执行的一个建议，有时如果出于成本方面的考虑ORACLE也可能不会按提示进行。
    根据实践应用，一般不建议开发人员应用ORACLE提示，因为各个数据库及服务器性能情况不一样，很可能一个地方性能提升了，但另一个地方却下降了，
    ORACLE在SQL执行分析方面已经比较成熟，
    如果分析执行的路径不对首先应在数据库结构（主要是索引）、服务器当前性能（共享内存、磁盘文件碎片）、数据库对象（表、索引）统计信息是否正确这几方面分析