Материализованное представление производительности Exists vs In - PullRequest
Новая
       35

Материализованное представление производительности Exists vs In

5 голосов
/ 19 марта 2020

Я немного погуглил и не смог найти четкого ответа на вопрос о производительности oracle. Возможно мы можем зарегистрировать это здесь. Я строю MV, который довольно прост, но на довольно больших столах. Запрос, как и многие вещи, может быть написан более чем одним способом. В моем случае, когда написано как оператор выбора, два решения имеют схожие затраты / план выполнения, но когда они размещены внутри представления с материализацией создания, время выполнения резко меняется. Любое понимание, почему?

  • Tab1 - это приблизительно 40M записей.
  • Tab2 - это записи aprox 8M.
  • field1 - это первичный ключ на Tab1, он не является PK или уникальным на Tab2, но на вкладке 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
)
;

Два запроса в виде операторов выбора выполняются во времени одинаково, и план объяснения предполагает, что оба они используют сканирование индекса, а не полное сканирование таблицы, как я ожидал. Что неожиданно, так это то, что Q2 работает намного быстрее (47 секунд против 81 дня на v $ session_longops) при запуске в создании mv, например: 

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

Есть ли у кого-нибудь понимание, есть ли здесь правило не использовать IN, если это возможно, только для mviews? Я знаю хитрости между и существовать, когда между таблицами не существует индексов, но этот сбил меня с толку. Это работает с базой данных oracle 11g.

1 Ответ

3 голосов
/ 19 марта 2020

Это похоже на известную ошибку. Если у вас есть доступ к моей Oracle поддержке, посмотрите на Медленное создание / обновление sh материализованного представления на основе запроса NOT IN Definition (Do c ID 1591851.1) или менее полезно, если вы не t, доступно краткое изложение проблемы .

Содержимое версии MOS, конечно, не может быть воспроизведено здесь, но достаточно сказать, что единственным обходным решением является то, что вы уже делаю с not exists. Это исправлено в 12 c, что вам мало поможет.

...