Question

当我在Oracle SQL中运行此查询时;

SELECT 
       ImportRef.GL_SL_LINK_ID, ImportRef.GL_SL_LINK_TABLE, Combos.Segment5
FROM GL_IMPORT_REFERENCES ImportRef
JOIN GL.GL_JE_LINES GLLines
     ON GLLines.JE_HEADER_ID = ImportRef.JE_HEADER_ID 
     AND GLLines.JE_LINE_NUM = ImportRef.JE_LINE_NUM
JOIN GL.GL_CODE_COMBINATIONS Combos
     ON Combos.CODE_COMBINATION_ID = GLLines.CODE_COMBINATION_ID
JOIN XLA.XLA_AE_LINES XLAL
     ON ImportRef.GL_SL_LINK_ID = XLAL.GL_SL_LINK_ID
     AND ImportRef.GL_SL_LINK_TABLE = XLAL.GL_SL_LINK_TABLE
WHERE
     Combos.Segment1 = '310'
     AND GLLines.PERIOD_NAME IN ('10-13')
     AND ImportRef.GL_SL_LINK_ID != 352258267
     AND ImportRef.GL_SL_LINK_ID != 248391353
ORDER BY GL_SL_LINK_ID;

它会在几秒钟内运行并返回44000行。

如果我删除;

     AND ImportRef.GL_SL_LINK_ID != 352258267
     AND ImportRef.GL_SL_LINK_ID != 248391353

它被卡住并且需要很长时间才能运行我必须放弃。看看表格中的这些行，我看不出有什么特别或不寻常的。任何想法为什么2看似随机行可能会对查询产生这样的影响？

回复评论;

我最初是通过SQL Server中的OPENQUERY运行查询，它将行返回到这些行，然后被“卡住”作为测试我刚刚排除了下一条记录，突然之间就有效了。

XLA_AE_LINES XLAL上有一个索引为;

GL_SL_LINK_ID＆amp;上的

GL_SL_LINK_TABLE

回应Simon Krenger;

快速查询;

Operation               Object Name         Rows    Bytes   Cost                                 SELECT STATEMENT Optimizer Mode=ALL_ROWS               27 K        1410564                                 SORT ORDER BY                               27 K    1 M 1410564                              
    NESTED LOOPS                            27 K    1 M 1410078                              
      NESTED LOOPS                          22 K    1 M 117603                               
        NESTED LOOPS                            8 K 317 K   64956                                
          TABLE ACCESS BY INDEX ROWID   GL.GL_CODE_COMBINATIONS     7 K 119 K   349                              
            INDEX RANGE SCAN        GL.GL_CODE_COMBINATIONS_N1  7 K     23                               
          TABLE ACCESS BY INDEX ROWID   GL.GL_JE_LINES          1   23  10                               
            INDEX RANGE SCAN        GL.GL_JE_LINES_N1       19      3                                
        TABLE ACCESS BY INDEX ROWID GL.GL_IMPORT_REFERENCES     3   63  8                                
          INDEX RANGE SCAN      GL.GL_IMPORT_REFERENCES_N1  23      3                                
      PARTITION LIST ALL                        1   14  57       
        INDEX RANGE SCAN        XLA.XLA_AE_LINES_N4     1   14  57

慢查询;

操作对象名称行字节成本

SELECT STATEMENT Optimizer Mode=ALL_ROWS                74 K        2630601                                 
  SORT ORDER BY                             74 K    5 M 2630601                                 
    HASH JOIN                               74 K    5 M 2629290                                 
      NESTED LOOPS                                               
        NESTED LOOPS                            59 K    3 M 117602                                   
          NESTED LOOPS                          8 K 317 K   64956                                
            TABLE ACCESS BY INDEX ROWID GL.GL_CODE_COMBINATIONS     7 K 119 K   349                                  
              INDEX RANGE SCAN      GL.GL_CODE_COMBINATIONS_N1  7 K     23                                   
            TABLE ACCESS BY INDEX ROWID GL.GL_JE_LINES          1   23      10                                   
              INDEX RANGE SCAN      GL.GL_JE_LINES_N1       19          3                                
          INDEX RANGE SCAN      GL.GL_IMPORT_REFERENCES_N1  23          3                                
        TABLE ACCESS BY INDEX ROWID GL.GL_IMPORT_REFERENCES 7   147     8                                
      PARTITION LIST ALL                        355 M   4G  1999069                         
        INDEX FULL SCAN                 XLA.XLA_AE_LINES_N4     355 M   4G  1999069

最大的区别似乎是从RANGE SCAN切换到FULL SCAN到最后我可以看到为什么会减慢它但不确定为什么它会像那样改变，任何想法？

2行停止选择查询运行

0 个答案: