Question

下面的简单SQL将返回1条记录，执行速度非常快。它也有很好的解释计划（使用P1索引作为主键索引）。

唯一的问题是它需要巨大的缓冲区，即字节数= 347百万（以下是从计划中复制的）。

6 TABLE ACCESS BY INDEX ROWID TABLE SIEBEL.S_ORG_EXT Cost: 2  Bytes: 347,432,257  Cardinality: 9,390,061

表S_ORG_EXT和S_OPTY具有巨大的数量。这是我无法控制的。您是否知道如何优化计划以使用较小的缓冲区？

提前致谢！

SQL：

SELECT A1.NAME
  FROM SIEBEL.S_ORG_EXT A1, SIEBEL.S_OPTY A3, SIEBEL.S_BU A4
 WHERE     A1.ROW_ID = A3.PR_DEPT_OU_ID                                    --4
       AND A3.ROW_ID = :V1                                                 --1
       AND A4.ROW_ID = A3.BU_ID                                            --2
       AND A3.PR_DEPT_OU_ID IS NOT NULL                                    --3

计划

SELECT STATEMENT  ALL_ROWSCost: 5  Bytes: 77  Cardinality: 1                
    7 NESTED LOOPS  Cost: 5  Bytes: 77  Cardinality: 1              
        4 NESTED LOOPS  Cost: 3  Bytes: 40  Cardinality: 1          
            2 TABLE ACCESS BY INDEX ROWID TABLE SIEBEL.S_OPTY Cost: 3  Bytes: 31  Cardinality: 1    
                1 INDEX UNIQUE SCAN INDEX (UNIQUE) SIEBEL.S_OPTY_P1 Cost: 2  Cardinality: 1  
            3 INDEX UNIQUE SCAN INDEX (UNIQUE) SIEBEL.S_BU_P1 Cost: 0  Bytes: 1,485  Cardinality: 165   
        6 TABLE ACCESS BY INDEX ROWID TABLE SIEBEL.S_ORG_EXT Cost: 2  Bytes: 347,432,257  Cardinality: 9,390,061        
            5 INDEX UNIQUE SCAN INDEX (UNIQUE) SIEBEL.S_ORG_EXT_P1 Cost: 1  Cardinality: 1

Answer 1

您不需要优化计划，因为您已经知道sql运行速度很快，而字节是行源返回多少字节的估计值。对于非常大的表，嵌套循环不是最有效的，som取决于您可以使用use_hash提示进行散列连接或设置optimizer_index_caching（http://docs.oracle.com/cd/B19306_01/server.102/b14237/initparams143.htm）的其他表的大小

SQL解释计划调优

1 个答案: