记一个SQL优化案例

某省电信在做批扣（批销）时，出现严重的性能问题，发现下面这一条SQL性能非常低下：

SELECT A.ACCT_BALANCE_ID,
       A.BALANCE_TYPE_ID,
       A.ACCT_ID,
       NVL(A.SERV_ID, -1) SERV_ID,
       NVL(A.ITEM_GROUP_ID, -1) ITEM_GROUP_ID,
       A.OBJECT_TYPE_ID,
       F.PRIORITY,
       A.BALANCE,
       NVL(A.CYCLE_UPPER, -1) CYCLE_UPPER,
       NVL(A.CYCLE_LOWER, -1) CYCLE_LOWER,
       NVL(A.CYCLE_UPPER_TYPE, ’ ’) CYCLE_UPPER_TYPE,
       NVL(A.CYCLE_LOWER_TYPE, ’ ’) CYCLE_LOWER_TYPE,
       B.ADJUST_FLAG ADJUST_FLAG,
       B.ALLOW_TRANS ALLOW_TRANS,
       B.CORPUS_FLAG,
       NVL(TO_CHAR(A.EFF_DATE, ’YYYYMMDDHH24MISS’), ’ ’) EFF_DATE,
       NVL(TO_CHAR(A.EXP_DATE, ’YYYYMMDDHH24MISS’), ’ ’) EXP_DATE,
       A.STATE,
       TO_CHAR(A.STATE_DATE, ’YYYYMMDDHH24MISS’) STATE_DATE,
       B.BALANCE_TYPE_NAME,
       NVL(C.ACCT_NAME, ’ ’) ACCT_NAME,
       NVL(D.ACC_NBR, ’ ’) SERV_NAME,
       NVL(E.ITEM_GROUP_NAME, ’ ’) ITEM_GROUP_NAME
  FROM (SELECT ACCT_BALANCE_ID,
               BALANCE_TYPE_ID,
               ACCT_ID,
               NVL(SERV_ID, -1) SERV_ID,
               NVL(ITEM_GROUP_ID, -1) ITEM_GROUP_ID,
               OBJECT_TYPE_ID,
               BALANCE,
               NVL(CYCLE_UPPER, -1) CYCLE_UPPER,
               NVL(CYCLE_LOWER, -1) CYCLE_LOWER,
               NVL(CYCLE_UPPER_TYPE, ’ ’) CYCLE_UPPER_TYPE,
               NVL(CYCLE_LOWER_TYPE, ’ ’) CYCLE_LOWER_TYPE,
               EFF_DATE,
               EXP_DATE,
               STATE,
               STATE_DATE,
               0 SHARE_RULE_PRIORITY
          FROM ACCT_BALANCE
         WHERE ACCT_ID = :LACCTID
           AND BALANCE > 0
           AND BALANCE_TYPE_ID != 1
           AND STATE = ’10A’
        UNION
        SELECT A1.ACCT_BALANCE_ID,
               A1.BALANCE_TYPE_ID,
               B1.ACCT_ID,
               NVL(B1.SERV_ID, -1) SERV_ID,
               NVL(B1.ITEM_GROUP_ID, -1) ITEM_GROUP_ID,
               A1.OBJECT_TYPE_ID,
               A1.BALANCE,
               NVL(B1.UPPER_AMOUNT, -1) CYCLE_UPPER,
               NVL(B1.LOWER_AMOUNT, -1) CYCLE_LOWER,
               NVL(A1.CYCLE_UPPER_TYPE, ’ ’) CYCLE_UPPER_TYPE,
               NVL(A1.CYCLE_LOWER_TYPE, ’ ’) CYCLE_LOWER_TYPE,
               A1.EFF_DATE,
               A1.EXP_DATE,
               A1.STATE,
               A1.STATE_DATE,
               B1.PRIORITY SHARE_RULE_PRIORITY
          FROM ACCT_BALANCE A1, BALANCE_SHARE_RULE B1
         WHERE A1.ACCT_BALANCE_ID = B1.ACCT_BALANCE_ID
           AND B1.ACCT_ID = :LACCTID
           AND A1.BALANCE > 0
           AND A1.BALANCE_TYPE_ID != 1
           AND A1.STATE = ’10A’
           AND NVL(B1.EFF_DATE, SYSDATE) < = SYSDATE
           AND NVL(B1.EXP_DATE, SYSDATE) >= SYSDATE) A,
       BALANCE_TYPE B,
       ACCT C,
       SERV D,
       A_BALANCE_ITEM_GROUP E,
       A_BALANCE_OBJECT_TYPE F
 WHERE A.BALANCE_TYPE_ID = B.BALANCE_TYPE_ID
   AND A.OBJECT_TYPE_ID = F.OBJECT_TYPE_ID
   AND A.ACCT_ID = C.ACCT_ID
   AND A.SERV_ID = D.SERV_ID(+)
   AND A.ITEM_GROUP_ID = E.ITEM_GROUP_ID(+)
 ORDER BY F.PRIORITY,
          B.PRIORITY,
          A.SHARE_RULE_PRIORITY ASC,
          A.EXP_DATE ASC,
          A.EFF_DATE ASC,
          A.BALANCE ASC

查看执行计划：

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                    |  Name                       | Rows  | Bytes |TempSpc| Cost  | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                             |                             |  2723G|   696T|       |  7776M|       |       |
|   1 |  SORT ORDER BY                               |                             |  2723G|   696T|  1503T|  7776M|       |       |
|*  2 |   HASH JOIN                                  |                             |  2723G|   696T|    59M| 39355 |       |       |
|*  3 |    HASH JOIN                                 |                             |   228K|    56M|       | 23918 |       |       |
|   4 |     TABLE ACCESS FULL                        | BALANCE_TYPE                |     8 |   184 |       |     7 |       |       |
|*  5 |     HASH JOIN                                |                             |   228K|    51M|       | 23907 |       |       |
|   6 |      TABLE ACCESS FULL                       | A_BALANCE_OBJECT_TYPE       |     4 |    16 |       |     7 |       |       |
|*  7 |      HASH JOIN OUTER                         |                             |   228K|    50M|    43M| 23896 |       |       |
|*  8 |       HASH JOIN OUTER                        |                             |   228K|    40M|    38M| 23199 |       |       |
|   9 |        VIEW                                  |                             |   228K|    36M|       |  2043 |       |       |
|  10 |         SORT UNIQUE                          |                             |   228K|    11M|    38M|  2043 |       |       |
|  11 |          UNION-ALL                           |                             |       |       |       |       |       |       |
|* 12 |           TABLE ACCESS BY GLOBAL INDEX ROWID | ACCT_BALANCE                |   228K|    11M|       |    50 | ROWID | ROW L |
|* 13 |            INDEX RANGE SCAN                  | IDX_ACCT_BALANCE_ACCT_ID42  |   121K|       |       |     3 |       |       |
|  14 |           NESTED LOOPS                       |                             |     1 |   146 |       |     4 |       |       |
|* 15 |            TABLE ACCESS FULL                 | BALANCE_SHARE_RULE          |     1 |   109 |       |     2 |       |       |
|* 16 |            TABLE ACCESS BY GLOBAL INDEX ROWID| ACCT_BALANCE                |     1 |    37 |       |     2 | ROWID | ROW L |
|* 17 |             INDEX UNIQUE SCAN                | PK_P_ACCT_BALANCE2          |     1 |       |       |     1 |       |       |
|  18 |        PARTITION RANGE ALL                   |                             |       |       |       |       |     1 |    63 |
|  19 |         TABLE ACCESS FULL                    | SERV                        |    12M|   258M|       | 14070 |     1 |    63 |
|  20 |       TABLE ACCESS FULL                      | A_BALANCE_ITEM_GROUP        |   244 | 11224 |       |     7 |       |       |
|  21 |    PARTITION RANGE ALL                       |                             |       |       |       |       |     1 |    63 |
|  22 |     TABLE ACCESS FULL                        | ACCT                        |    11M|   239M|       |  8505 |     1 |    63 |
------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access(”A”.”ACCT_ID”=”C”.”ACCT_ID”)
3 - access(”A”.”BALANCE_TYPE_ID”=”B”.”BALANCE_TYPE_ID”)
5 - access(”A”.”OBJECT_TYPE_ID”=”F”.”OBJECT_TYPE_ID”)
7 - access(”A”.”ITEM_GROUP_ID”=”E”.”ITEM_GROUP_ID”(+))
8 - access(”A”.”SERV_ID”=”D”.”SERV_ID”(+))
12 - filter(”ACCT_BALANCE”.”BALANCE”>0 AND “ACCT_BALANCE”.”BALANCE_TYPE_ID”<>1 AND “ACCT_BALANCE”.”STATE”=’10A’)
13 - access(”ACCT_BALANCE”.”ACCT_ID”=TO_NUMBER(:Z))
15 - filter(”B1″.”ACCT_ID”=TO_NUMBER(:Z) AND NVL(”B1″.”EFF_DATE”,SYSDATE@!)< =SYSDATE@! AND
NVL("B1"."EXP_DATE",SYSDATE@!)>=SYSDATE@!)
16 - filter(”A1″.”BALANCE”>0 AND “A1″.”BALANCE_TYPE_ID”<>1 AND “A1″.”STATE”=’10A’)
17 - access(”A1″.”ACCT_BALANCE_ID”=”B1″.”ACCT_BALANCE_ID”)

从执行计划来看，Oracle评估出来的COST是相当的惊人（7776M），而返回的行数是2723G。看起来应该是统计信息不准确导致了选择了错误的执行计划。

对于一个SQL，如果其执行计划错误地采用于full table scan和hash join，则一般是由于评估表访问返回的数据行数过多，使其高估了成本。反之，如果是错误地采用了索引扫描，则一般是由于评估表访问返回的数据行数太少，使其低估了成本。

我们来分析这个执行计划。首先查看访问表时，Oracle评估返回的行的数目是否有偏大的情况。我们发现看以下的几行，返回的结果集行数很高：

|* 12 |           TABLE ACCESS BY GLOBAL INDEX ROWID | ACCT_BALANCE                |   228K|    11M|       |    50 | ROWID | ROW L |
|* 13 |            INDEX RANGE SCAN                  | IDX_ACCT_BALANCE_ACCT_ID42  |   121K|       |       |     3 |       |       |
|  19 |         TABLE ACCESS FULL                    | SERV                        |    12M|   258M|       | 14070 |     1 |    63 |
|  22 |     TABLE ACCESS FULL                        | ACCT                        |    11M|   239M|       |  8505 |     1 |    63 |

最值得怀疑的首先是第12行和第13行。第13行是一个索引范围扫描，返回的结果集行数居然有121K行，而这个访问条件只是 “access(”ACCT_BALANCE”.”ACCT_ID”=TO_NUMBER(:Z))”，从业务上来看，看起来这条SQL是查询某个帐户的 余额及其他信息的。输入的条件为ACCT_ID，而一般来说，帐户余额表中，一个ACCT_ID的对应的行，只有很少的行（10行以下），而不会返回这么 多行。

IDX_ACCT_BALANCE_ACCT_ID42这个索引，是一个在ACCT_BALANCE表（这是个分区表）的ACCT_ID上的全局普 通索引(GLOBAL NORMAL INDEX)。检查统计信息，这个表是当天才收集的，ACCT_ID这个字段没有任何统计信息（已经被删除）。同时索引中的统计信息如下：

Index                      Tree Leaf       Distinct         Number Leaf Blocks Data Blocks      Cluster
Name            Unique    Level Blks           Keys        of Rows     Per Key     Per Key       Factor
--------------- --------- ----- ---- -------------- -------------- ----------- ----------- ------------
IDX_ACCT_BALANC NONUNIQUE     2 ####        580,079     30,742,660           1          47   27,447,720
E_ACCT_ID42                                                                                            

看起来索引的Distinct Keys值太小，才580,079。索引的总行数为30,742,660。重新分析该索引后，Distinct Keys的值才是正确的值：10,540,493。
再看看ACCT_BALANCE表中的ACCT_ID字段，由于没有统计信息，那么Oracle会使用一个默认的选择率（对于表的单个字段条件过滤，一般 是1%）。对于这样一个3000多万行的表来说，默认的选择率造成评估的返回行数过高。由于正是出帐期间，重新分析这样一个表，影响是非常大的，而这个表 之前刚分析过。我们这里可以使用DBMS_STATS.SET_COLUMN_STATS过程手工设置统计信息：

SQL> exec dbms_stats.set_column_stats(ownname=>user,tabname=>’ACCT_BALANCE’,colname=>’ACCT_ID’,
NULLCNT=>0,DENSITY=>1/10540393,DISTCNT=>10540393);

这里的统计信息来自于ACCT_ID字段上的索引（ACCT_ID字段定义为NOT NULL，所以比较方便地手工计算出这些统计信息）。

我们再次查看执行计划：

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                    |  Name                       | Rows  | Bytes |TempSpc| Cost  | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                             |                             |    35M|  9603M|       |  1472K|       |       |
|   1 |  SORT ORDER BY                               |                             |    35M|  9603M|    20G|  1472K|       |       |
|   2 |   NESTED LOOPS                               |                             |    35M|  9603M|       |    62 |       |       |
|   3 |    NESTED LOOPS OUTER                        |                             |     3 |   780 |       |    56 |       |       |
|   4 |     NESTED LOOPS OUTER                       |                             |     3 |   717 |       |    50 |       |       |
|   5 |      NESTED LOOPS                            |                             |     3 |   579 |       |    47 |       |       |
|   6 |       NESTED LOOPS                           |                             |     3 |   510 |       |    44 |       |       |
|   7 |        VIEW                                  |                             |     3 |   498 |       |    42 |       |       |
|   8 |         SORT UNIQUE                          |                             |     3 |   248 |       |    42 |       |       |
|   9 |          UNION-ALL                           |                             |       |       |       |       |       |       |
|* 10 |           TABLE ACCESS BY GLOBAL INDEX ROWID | ACCT_BALANCE                |     2 |   102 |       |     6 | ROWID | ROW L |
|* 11 |            INDEX RANGE SCAN                  | IDX_ACCT_BALANCE_ACCT_ID42  |     3 |       |       |     3 |       |       |
|  12 |           NESTED LOOPS                       |                             |     1 |   146 |       |     4 |       |       |
|* 13 |            TABLE ACCESS FULL                 | BALANCE_SHARE_RULE          |     1 |   109 |       |     2 |       |       |
|* 14 |            TABLE ACCESS BY GLOBAL INDEX ROWID| ACCT_BALANCE                |     1 |    37 |       |     2 | ROWID | ROW L |
|* 15 |             INDEX UNIQUE SCAN                | PK_P_ACCT_BALANCE2          |     1 |       |       |     1 |       |       |
|  16 |        TABLE ACCESS BY INDEX ROWID           | A_BALANCE_OBJECT_TYPE       |     1 |     4 |       |     1 |       |       |
|* 17 |         INDEX UNIQUE SCAN                    | PK_A_BALANCE_OBJECT_TYPE    |     1 |       |       |       |       |       |
|  18 |       TABLE ACCESS BY INDEX ROWID            | BALANCE_TYPE                |     1 |    23 |       |     1 |       |       |
|* 19 |        INDEX UNIQUE SCAN                     | PK_BALANCE_TYPE             |     1 |       |       |       |       |       |
|  20 |      TABLE ACCESS BY INDEX ROWID             | A_BALANCE_ITEM_GROUP        |     1 |    46 |       |     1 |       |       |
|* 21 |       INDEX UNIQUE SCAN                      | PK_ITEM_GROUP_ID_HN         |     1 |       |       |       |       |       |
|  22 |     TABLE ACCESS BY GLOBAL INDEX ROWID       | SERV                        |     1 |    21 |       |     2 | ROWID | ROW L |
|* 23 |      INDEX UNIQUE SCAN                       | PK_SERV                     |     1 |       |       |     1 |       |       |
|  24 |    TABLE ACCESS BY GLOBAL INDEX ROWID        | ACCT                        |    11M|   239M|       |     2 | ROWID | ROW L |
|* 25 |     INDEX UNIQUE SCAN                        | PK_ACCT                     |     1 |       |       |     1 |       |       |
------------------------------------------------------------------------------------------------------------------------------------

现在可以看到，执行计划已经是改善了很多，只有唯一的一个全表扫描--BALANCE_SHARE_RULE，不过那个表的行数为0。

这个时候，客户反映系统正常了。虽然Oracle在ACCT表上评估返回的行数仍然很高，但是从系统故障处理这个角度上讲目的已经达到了。接下来就是处理这个ACCT表，类似的问题，类似的过程，这里不再细述。

总结：

此次性能问题的处理，从接到客户电话，到拨号连接，到最终处理完成，不到1小时。个人认为，这个处理速度还是比较快速的。做一个如下的总结：

• 了解SQL是干什么的（也就是理解SQL的业务），非常有助于调优。
• 调优需要善于与客户和开发沟通。
• 很多时候，现在ORACLE的优化器已经非常智能和完善，SQL性能问题是由于优化统计信息不准确。使用hint那个是治标不治 本。只有在非常复杂的SQL（比如有非常多的内联视图，子查询等等），才应该考虑HINT。这只是个人观点。当然还会有其他需要使用HINT才能解决的地 方。
• 善用脚本，这个案例中，我再次使用了sosi.sql这个脚本来查看表的优化统计信息，能够大大节约时间，同时查看的优化统计信息非常完整。
• 善用DBMS_STATS，在这个案例中，使用set_column_stats，大大节省了收集优化统计信息的时间。