Производительность Oracle - мне лучше начать с самого маленького набора результатов

Question

Просто поговорим с некоторыми парнями на работе о том, как лучше всего писать запросы и производительность.

Лучше ли ограничивать свой первый набор результатов, чтобы все соединения из исходной таблицы имели меньше строк для соединения?

Например:

ТАБЛИЦА: REFCODE имеет ~ 10000 строк

ТАБЛИЦА: товарный склад имеет ~ 200 строк

Что лучше для производительности?

Используя внутреннее соединение, чтобы сжать строки из большого результирующего набора:

SELECT 
    * 
FROM 
    REFCODE 
INNER JOIN 
    WHSE ON 
    WHSE.RCIDX = REFCODE.RCIDX 

Использование меньшего результирующего первого:

SELECT 
    * 
FROM 
    WHSE 
INNER JOIN 
    REFCODE ON 
    REFCODE.RCIDX = WHSE.RCIDX 

Используя большой набор результатов, но с использованием где клаузула фильтр только записи, которые, как я знаю, присоединятся ко второй таблице

SELECT 
    * 
FROM 
    REFCODE 
INNER JOIN 
    WHSE ON 
    WHSE.RCIDX = REFCODE.RCIDX 
WHERE 
    REFCODE.TYPE = 'WHSE' 

Или будет t он CBO определить план объяснения аналогичный? Мне сказали ребята здесь, что вы всегда должны начинать с самых маленьких результатов, но не уверены!

Любое обсуждение было воспринято!

Answer 1

Для простого случая, подобного тому, который вы опубликовали, оптимизатор почти наверняка создаст тот же план запроса для всех трех запросов. Не будет никакой разницы в производительности.

Как правило, порядок таблиц в запросе не имеет значения. Оптимизатор должен определить подходящий порядок соединения и метод объединения, основанный на статистике, собранной вами на объектах. Иногда, когда вы присоединяетесь к относительно большому количеству таблиц, оптимизатор не сможет рассматривать все возможные порядки соединения, потому что для этого потребуется превышение значения optimizer_max_permutations. Когда это происходит, оптимизатор использует эвристику, чтобы попытаться определить, какие пути следует рассмотреть подробно и которые игнорировать. Эти эвристики несовершенны, поэтому вы можете обнаружить, что есть случаи, когда оптимизатор устраняет путь, который привел бы к лучшему порядку соединения. Список наиболее ограничительных таблиц сначала может привести к смещению к планам, где это таблица вождения, которая, вероятно, будет наиболее эффективной. Но это очень угловой случай.

У Джонатана Льюиса хорошая статья о том, как the order of tables in the FROM clause can affect the query plan. Но для подавляющего большинства запросов, которые вы, вероятно, будете писать или встречаться, порядок таблиц не имеет значения.

Назад в старые дни оптимизатора правил, когда Oracle 7.3.4 был блестящим и новым, а динозавры перемещались по Земле, оптимизатор на основе правил использовал бы порядок таблиц для создания плана. Я соглашусь на то, что люди, с которыми вы разговариваете, либо достаточно стары, чтобы быть в те дни, либо передают правила, которым их учат те старые разработчики.

Несмотря на то, что в любом случае нет преимуществ (практически во всех случаях), последовательный подход к структурированию ваших запросов может быть полезным. Например, если вы всегда ставите ведущие таблицы, это может побудить разработчиков задуматься о ожидаемом плане запроса и немного задуматься над их кодом.И это может облегчить просмотр относительно быстро, если оптимизатор делает то, что вы ожидаете, когда он генерирует план запроса, чтобы указать вам на проблемы со статистикой, которые у вас есть на ваших объектах.