Oracle 11G - 加入时未使用 PK 索引，求助于全扫描

Question

我知道 Oracle 有时会“判断”执行全表扫描比索引扫描更好，但仍处于“学习阶段”，我只是想更好地了解 oracle“何时”会确定最佳路线。例如，我有一个简单的查询:

Select *
  FROM GLMV_JOURNAL_LOGS JLOG 
       INNER JOIN GLMV_Transact_Details TDTL 
          ON TDTL.TR_REF_NO = JLOG.TR_REF_NO 
         AND TDTL.SCAT_KEY = JLOG.Scat_key 
         AND TDTL.CASE_KEY = JLOG.CASE_KEY 
         AND TDTL.TR_CD = JLOG.TR_CD 
       INNER JOIN FUND_DESC FDDC 
          ON FDDC.FD_DESC_ID = TDTL.FD_DESC_ID  
       INNER JOIN FD_RATES FDRT 
          ON  FDRT.FDRT_KEY = TDTL.FDRT_KEY
       INNER JOIN BEN_TYPES BNTP 
          ON BNTP.BNTP_KEY = FDRT.BNTP_KEY 
 WHERE JLOG.JRNL_CD  = '0' 
   AND JLOG.SRC_CD = '2' 
   AND JLOG.MKEY_FD_NUM <> 0 
   AND NVL(JLOG.TMOV_KEY, -1) > 0 
   AND NVL(JLOG.ORIG_SCAT_KEY, 1) = 1 
   AND TDTL.STAT_CD <> '4' 
   AND NVL(TDTL.ORIG_SCAT_KEY, 1) = 1 

FD_RATES 上的连接是 PK 值上的连接，我还在 GLMV_Transact_Details 上创建了一个相应的索引，以为可以防止全表扫描，但是，根据下面的解释计划，即使在我已经执行索引重建并收集表统计信息，结果仍然相同:

现在，如果我进入查询并添加以下 where 子句:

AND  FDRT.FDRT_KEY = 100

索引当然会启动，但我想我很好奇为什么在进行内部联接时它没有启动......有什么提示吗？？

Answer 1

优化器估计 FD_RATES 上的全表扫描成本为 106。此馈入的连接估计基数为 416，其他行源馈入该连接也是如此。如果我们用嵌套循环替换散列连接，为每一行执行唯一索引 (PK) 查找，则循环的每次迭代的成本至少为 1，可能为 2 或 3，我们认为会有是 416 次迭代，所以这将是至少 416 的成本，可能是它的两倍或三倍，这比进行全表扫描的估计成本要高得多。

现在，估计可能是错误的。根据我的经验，主要要看的是计划中显示的基数。如果这些相当准确，那么 Oracle 很有可能选择了相当有效的连接顺序和访问路径——不一定是最有效的，但接近。

如果你想尝试强制索引扫描以查看它的性能，我相信你想要的提示是:

Select /*+ INDEX(fdrt) */ *
...