Exists vs In的材料化视图性能>

Question

我做了一些谷歌搜索，但是找不到针对Oracle性能问题的明确答案。也许我们可以在这里记录下来。我正在建立一个非常简单但在相当大的表上的MV。像许多事情一样，查询可以用多种方式编写。就我而言，当以选择语句的形式编写时，两个解决方案的成本/执行计划都差不多，但是当放置在创建实例化视图中时，执行时间将发生巨大变化。对为什么有任何见解？

• Tab1是aprox 40M记录。
• Tab2是aprox 8M记录。
• field1是Tab1上的主键，它不是PK或Tab2上的唯一键，但是Tab 2在此字段上确实具有索引。
• field2不是键，也不在任何一个表上索引（boo）

查询是：

Q1：

SELECT
    CR1.Several_Fields
FROM 
    SCHEMA1.tab1 T1
WHERE T1.field2 like 'EXAMPLE%'
AND T1.field1 not in (
    SELECT T2.field1
    FROM SCHEMA1.tab2 T2
)
; 

Q2：

SELECT
    CR1.Several_Fields
FROM 
    SCHEMA1.tab1 T1
WHERE T1.field2 like 'EXAMPLE%'
AND  not exists (
    SELECT 1
    FROM SCHEMA1.tab2 T2
    WHERE T1.field1 = T2.field1
)
;

这两个查询作为select语句的运行时间类似，并且说明计划中它们都利用索引扫描而不是我期望的全表扫描。出乎意料的是，当在MV创建中运行时，Q2的运行速度大大加快（47秒，每个v $ session_longops为81天，相比）：

CREATE MATERIALIZED VIEW SCHEMA1.mv_blah as
(
  Q1 or Q2
);
没有人有任何见识，这里是否有一条规则，如果可能的话，仅对mviews不使用IN？当表之间不存在索引，但是让我感到困惑时，我知道in和存在之间的窍门。这是针对oracle 11g数据库运行的。 

我做了一些谷歌搜索，但是找不到针对Oracle性能问题的明确答案。也许我们可以在这里记录下来。我正在建立一个非常简单但在相当大的表上的MV。查询...

Answer 1

这似乎是一个已知的错误。如果您有权访问My Oracle Support，请查看Slow Create/Refresh of Materialized View Based on NOT IN Definition Query (Doc ID 1591851.1)，如果没有访问权限，请查看a summary of the problem is available。