Oracle 计划将 'b' 与 'B' 998x 比较慢（10g 或 11g）

Question

有一个查询，通过与另一个表进行比较来将记录设置为坏记录。为了节省时间，我排除了已经标记为“不良”的记录。

我写了一个查询，但不小心检查了 != 'b' 而不是 != 'B'...查询在 0.203 秒内执行。当我意识到我的错误时，我将其更改为 != 'B'，但现在查询需要 200 多秒才能执行！！！

当我检查计划时，“b”的优化器选择了两个散列连接的串联。 'B' 的计划选择嵌套循环。

如果重要的话，我的测试没有任何标记为“B”的记录。 gsu.stg_userdata 中有约 18,000 条记录，gsu.userdata_compare 中有约 73,000 条记录。两个查询都得出相同（且正确）数量的结果。

查询：

select gstgu.global_id
from   gsu.stg_userdata gstgu
  left join gsu.userdata_compare guc
    on (gstgu.global_id = guc.global_id) or (gstgu.user_id = guc.user_id)
where  gstgu.row_check != 'b' 
   and ((-- Global IDs match, but two different Network IDs are explicitly set
         (gstgu.global_id = guc.global_id) and (guc.user_id is not null and 
                                                gstgu.user_id is not null and
                                                guc.user_id != gstgu.user_id))
         -- Network IDs match, but two different Global IDs are explicitly set
      or (guc.user_id = gstgu.user_id and (guc.global_id is not null and 
                                           gstgu.global_id is not null and
                                           guc.global_id != gstgu.global_id))
      or length(gstgu.global_id) != 8)
   and guc.global_id != '00000000';

--

这条sql的计划：

                                                 Cost   Card   Bytes
SELECT STATEMENT, GOAL = ALL_ROWS                1014   1410   49350
 CONCATENATION          
  HASH JOIN                                       507    559   19565
   TABLE ACCESS FULL       GSU  STG_USERDATA      205  11144  189448
   INDEX FAST FULL SCAN    GSU  USERCOMPARE_IDX   302  16979  305622
  HASH JOIN                                       507    851   29785
   INDEX FAST FULL SCAN    GSU  USERCOMPARE_IDX   302  16979  305622
   TABLE ACCESS FULL       GSU  STG_USERDATA      205  17949  305133

如果我采用完全相同的查询，然后说

where  gstgu.row_check != 'B' 

执行需要 200 多秒（将近 1,000 倍的时间），计划如下：

                                                 Cost   Card   Bytes
SELECT STATEMENT, GOAL = ALL_ROWS                 507      1      35
 NESTED LOOPS                                     507      1      35
  TABLE ACCESS FULL        GSU  STG_USERDATA      205      1      17
  INDEX FAST FULL SCAN     GSU  USERCOMPARE_IDX   302      1      18

我快疯了，是什么原因？？

.

Answer 1

为 Row_check 字段添加索引 .... 大多数情况下，此问题是由此引起的。