Exists 与 In 的物化视图性能

Question

我进行了一些谷歌搜索，但找不到 oracle 性能问题的明确答案。也许我们可以在这里记录下来。我正在构建一个非常简单但相当大 tables 的 MV。像许多事情一样，查询可以用不止一种方式编写。在我的例子中，当写成 select 语句时，两个解决方案具有相似的成本/执行计划，但是当放置在创建实体化视图中时，执行时间会发生巨大变化。对原因有何见解？

Tab1 大约有 40M 条记录。
Tab2 大约有 8M 条记录。
field1 是 Tab1 上的主键，它不是 Tab2 上的主键或唯一键，但选项卡 2 确实在此字段上有索引。
field2 不是键，也没有在 table 上建立索引（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 语句运行的时间相似，并且解释计划让它们都使用索引扫描而不是我所期望的完整 table 扫描。出乎意料的是，Q2 运行s 快得多（每个 v$session_longops 47 秒 vs 81 天）当运行在 mv 创作中，如：

CREATE MATERIALIZED VIEW SCHEMA1.mv_blah as
(
  Q1 or Q2
);

有没有人有任何见解，这里是否有一条规则，如果可能只对 mviews 不使用 IN？当 table 之间不存在索引时，我知道 in 和 exist 之间的技巧，但这让我感到困惑。这是针对 oracle 11g 数据库的运行ning。

Answer 1

这看起来像是一个已知错误。如果您有权访问 My Oracle Support，请查看 Slow Create/Refresh of Materialized View Based on NOT IN Definition Query (Doc ID 1591851.1), or less usefully if you don't, a summary of the problem is available.

这里当然不能复制 MOS 版本的内容，但可以说唯一的解决方法就是您已经使用 not exists 所做的事情。它在 12c 中已修复，这对您没有太大帮助。

Exists 与 In 的物化视图性能

Materialized View Performance of Exists vs In

sql

oracle

performance

materialized-views

Q1:

Q2：