当前位置: 首页 > 教程频道 > 数据库 > oracle >

sql优化 consistent gets与cost解决思路

2013-09-25
sql优化 consistent gets与cost执行计划----------------------Plan hash value: 2241963146-------------

sql优化 consistent gets与cost

执行计划
----------------------
Plan hash value: 2241963146

-------------------------------------------------------------------------
| Id  | Operation                        | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                          |     1 |   142 |    22   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE                  |                          |     1 |   142 |            |       |
|   2 |   NESTED LOOPS                   |                          |     1 |   142 |    22   (0)| 00:00:01 |
|   3 |    NESTED LOOPS                  |                          |     1 |   111 |    20   (0)| 00:00:01 |
|   4 |     NESTED LOOPS                 |                          |     1 |    88 |    19   (0)| 00:00:01 | 
 
|   5 |      NESTED LOOPS                |                          |     3 |   168 |    11   (0)| 00:00:01 |
|   6 |       TABLE ACCESS BY INDEX ROWID| WEB_APP_APPLICANT        |     3 |    99 |     5   (0)| 00:00:01 |
|*  7 |        INDEX RANGE SCAN          | PK_APP_APPLICANT_APPNME  |     3 |       |     3   (0)| 00:00:01 |
|*  8 |       INDEX RANGE SCAN           | IDX_APP_INSURED_APPNO    |     1 |    23 |     2   (0)| 00:00:01 |
|*  9 |      TABLE ACCESS BY INDEX ROWID | WEB_PAY_CONFIRM_INFO     |     1 |    32 |     3   (0)| 00:00:01 |
|* 10 |       INDEX RANGE SCAN           | IDX_PAYCONFIRMINFO_APPNO |     1 |       |     2   (0)| 00:00:01 |
|* 11 |     INDEX UNIQUE SCAN            | PK_WEB_APP_VHL           |     1 |    23 |     1   (0)| 00:00:01 |
|* 12 |    TABLE ACCESS BY INDEX ROWID   | WEB_APP_BASE             |     1 |    31 |     2   (0)| 00:00:01 |
|* 13 |     INDEX UNIQUE SCAN            | PK_WEB_APP_BASE          |     1 |       |     1   (0)| 00:00:01 | 
 
-------------------------------------------------------------------------

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

   7 - access("APPAPPLICA2_"."C_APP_NME" LIKE '江苏万帮汽车有限公司%')
       filter("APPAPPLICA2_"."C_APP_NME" LIKE '江苏万帮汽车有限公司%')
   8 - access("APPINSURED1_"."C_APP_NO"="APPAPPLICA2_"."C_APP_NO")
   9 - filter("PAYCONFIRM0_"."C_REG_DPT_CDE"='0401' AND "PAYCONFIRM0_"."C_CHECK_STS"='00' AND
              ("PAYCONFIRM0_"."C_PROD_NO"='0320' OR "PAYCONFIRM0_"."C_PROD_NO"='0325' OR
              "PAYCONFIRM0_"."C_PROD_NO"='0326' OR "PAYCONFIRM0_"."C_PROD_NO"='0327' OR
              "PAYCONFIRM0_"."C_PROD_NO"='0329') AND "PAYCONFIRM0_"."C_CHECK_STS"<>'8')
  10 - access("PAYCONFIRM0_"."C_APP_NO"="APPINSURED1_"."C_APP_NO")
  11 - access("PAYCONFIRM0_"."C_APP_NO"="APPVHLVO4_"."C_APP_NO")
  12 - filter("APPBASEVO3_"."C_OPR_CDE"='910428')
  13 - access("APPAPPLICA2_"."C_APP_NO"="APPBASEVO3_"."C_APP_NO")


统计信息
----------------------
          1  recursive calls
          0  db block gets
       5267  consistent gets
        319  physical reads
        188  redo size
        335  bytes sent via SQL*Net to client
       1226  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

在进行sql解释计划分析的时候发现，有的sql consistent gets 很大，但是cost很小，就像上面的sql，这是什么原因呢？ 性能优化

SQL
[解决办法]

引用:
执行计划
----------------------
Plan hash value: 2241963146

-------------------------------------------------------------------------

[解决办法]
 Id  
[解决办法]
 Operation                        
[解决办法]
 Name                     
[解决办法]
 Rows  
[解决办法]
 Bytes 
[解决办法]
 Cost (%CPU)
[解决办法]
 Time     
[解决办法]

-------------------------------------------------------------------------

[解决办法]
   0 
[解决办法]
 SELECT STATEMENT                 
[解决办法]
                          
[解决办法]
     1 
[解决办法]
   142 
 
 [解决办法]
    22   (0)
[解决办法]
 00:00:01 
[解决办法]


[解决办法]
   1 
[解决办法]
  SORT AGGREGATE                  
[解决办法]
                          
[解决办法]
     1 
[解决办法]
   142 
[解决办法]
            
[解决办法]
       
[解决办法]


[解决办法]
   2 
[解决办法]
   NESTED LOOPS                   
[解决办法]
                          
[解决办法]
     1 
[解决办法]
   142 
[解决办法]
    22   (0)
[解决办法]
 00:00:01 
[解决办法]


------解决方案-------------------- 
 
   3 
[解决办法]
    NESTED LOOPS                  
[解决办法]
                          
[解决办法]
     1 
[解决办法]
   111 
[解决办法]
    20   (0)
[解决办法]
 00:00:01 
[解决办法]


[解决办法]
   4 
[解决办法]
     NESTED LOOPS                 
[解决办法]
                          
[解决办法]
     1 
[解决办法]
    88 
[解决办法]
    19   (0)
[解决办法]
 00:00:01 
[解决办法]


[解决办法]
   5 
[解决办法]
      NESTED LOOPS                
[解决办法]
                           
 
[解决办法]
     3 
[解决办法]
   168 
[解决办法]
    11   (0)
[解决办法]
 00:00:01 
[解决办法]


[解决办法]
   6 
[解决办法]
       TABLE ACCESS BY INDEX ROWID
[解决办法]
 WEB_APP_APPLICANT        
[解决办法]
     3 
[解决办法]
    99 
[解决办法]
     5   (0)
[解决办法]
 00:00:01 
[解决办法]


[解决办法]
*  7 
[解决办法]
        INDEX RANGE SCAN          
[解决办法]
 PK_APP_APPLICANT_APPNME  
[解决办法]
     3 
[解决办法]
       
[解决办法]
     3   (0)
[解决办法]
 00:00:01 
[解决办法]


------解决方案-------------------- 
 
*  8 
[解决办法]
       INDEX RANGE SCAN           
[解决办法]
 IDX_APP_INSURED_APPNO    
[解决办法]
     1 
[解决办法]
    23 
[解决办法]
     2   (0)
[解决办法]
 00:00:01 
[解决办法]


[解决办法]
*  9 
[解决办法]
      TABLE ACCESS BY INDEX ROWID 
[解决办法]
 WEB_PAY_CONFIRM_INFO     
[解决办法]
     1 
[解决办法]
    32 
[解决办法]
     3   (0)
[解决办法]
 00:00:01 
[解决办法]


[解决办法]
* 10 
[解决办法]
       INDEX RANGE SCAN           
[解决办法]
 IDX_PAYCONFIRMINFO_APPNO 
[解决办法]
     1 
[解决办法]
       
------解决方案-------------------- 
 
     2   (0)
[解决办法]
 00:00:01 
[解决办法]


[解决办法]
* 11 
[解决办法]
     INDEX UNIQUE SCAN            
[解决办法]
 PK_WEB_APP_VHL           
[解决办法]
     1 
[解决办法]
    23 
[解决办法]
     1   (0)
[解决办法]
 00:00:01 
[解决办法]


[解决办法]
* 12 
[解决办法]
    TABLE ACCESS BY INDEX ROWID   
[解决办法]
 WEB_APP_BASE             
[解决办法]
     1 
[解决办法]
    31 
[解决办法]
     2   (0)
[解决办法]
 00:00:01 
[解决办法]


[解决办法]
* 13 
[解决办法]
     INDEX UNIQUE SCAN            
------解决方案-------------------- 
 
 PK_WEB_APP_BASE          
[解决办法]
     1 
[解决办法]
       
[解决办法]
     1   (0)
[解决办法]
 00:00:01 
[解决办法]

-------------------------------------------------------------------------

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

   7 - access("APPAPPLICA2_"."C_APP_NME" LIKE '江苏万帮汽车有限公司%')
       filter("APPAPPLICA2_"."C_APP_NME" LIKE '江苏万帮汽车有限公司%')
   8 - access("APPINSURED1_"."C_APP_NO"="APPAPPLICA2_"."C_APP_NO")
   9 - filter("PAYCONFIRM0_"."C_REG_DPT_CDE"='0401' AND "PAYCONFIRM0_"."C_CHECK_STS"='00' AND
              ("PAYCONFIRM0_"."C_PROD_NO"='0320' OR "PAYCONFIRM0_"."C_PROD_NO"='0325' OR
              "PAYCONFIRM0_"."C_PROD_NO"='0326' OR "PAYCONFIRM0_"."C_PROD_NO"='0327' OR
              "PAYCONFIRM0_"."C_PROD_NO"='0329') AND "PAYCONFIRM0_"."C_CHECK_STS"<>'8')
  10 - access("PAYCONFIRM0_"."C_APP_NO"="APPINSURED1_"."C_APP_NO")
  11 - access("PAYCONFIRM0_"."C_APP_NO"="APPVHLVO4_"."C_APP_NO")
  12 - filter("APPBASEVO3_"."C_OPR_CDE"='910428')
  13 - access("APPAPPLICA2_"."C_APP_NO"="APPBASEVO3_"."C_APP_NO")


统计信息
----------------------
          1  recursive calls
          0  db block gets
       5267  consistent gets
        319  physical reads
        188  redo size
        335  bytes sent via SQL*Net to client
       1226  bytes received via SQL*Net from client 
 
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

在进行sql解释计划分析的时候发现，有的sql consistent gets 很大，但是cost很小，就像上面的sql，这是什么原因呢？


consistent gets 很大没有什么问题.

如果physical reads 很大,才会有很大问题.

consistent gets 你可以理解为从内存(SGA中的相关内存存储)取出来的数据,由于内存的存取速度非常快,因此这个大一点没有什么关系.

physical reads 你可以理解为从内存中读取数据(物理读),这个因为反复读取硬盘信息,而现在的硬盘IO速度一直比较慢,因此经常会出现physical reads比较大的时候,硬盘灯是不断闪烁的.

影响COST的一个比较重要的指标就是physical reads.

阅读人气排行