Все здравствуйте!

Есть внешний ключ. Допустимо пустое значение. Пустое значение логически соответствует принадлежности всем записям родительской таблицы.

Условие присоединения


делает выборку по таблице CHILD_TABLE FULL SCAN и она получается не индексированной.

Что можно сделать?

Спасибо!!!!

кхе...  в топку бы такое 

под стать дизайну и решение.
Для того чтобы значение индекса не принимало не определенные значение - используем составной индекс, в который добавляем любое нот нулл поле, в результате получаем возможность индексного доступа по null.

  
Пример работает
Делаю все точно так же!!!!
В моей таблице - FULLL!!!!


Может еще нужно планы как-то инвалиднуть?

может для твоего случая фуллскан эффективнее? )
Для примера я специально выбирал именно такое сочетание данных чтобы на моем окружении индексный доступ  был эффективнее.

Добавлено через 45 секунд
Статистику после индексирования собирал?

Собирать - это строить или смотреть?
как это сделать?

GATHER_TABLE_STATS
14 Managing Optimizer Statistics

Статистику еще не собирал...
Но у меня возник вопрос. Это сарказм, или такое действительно может быть, что полное сканирование эффективнее?

Делаю выборку по значению -  индексирует
По is null - индексирует

по значению или is null - full scan, при этом выбираются 18,33% записей

если 18% от 1000 записей в таблице, то скорей всего так и есть. если их все же на порядок больше, то можно предположить что оптимайзер об этом незнает, в этом случае стоит собрать статистику, а потом разбираться.

Это не сарказм.

При принятии решения о том, что выгоднее - фуллскан+хэш джойн или нестед луп +  доступ по индексу учитывается очень большое количества параметров. Как то: количество блоков в таблице, стоимость операции многблочного чтения, стоимость одноблочного чтения, кластеризация индекса, отношение стоимостей IO и CPU...

Мой опыт показывает, что я ошибаюсь в своем представлении об эффективности плана намного чаще чем оптимизатор при наличии достоверной статистики. Самостоятельно влиять на план выполнения приходится только тогда, когда я заведомо знаю больше оптимизатора. При этом, до сих пор в продуктивных решениях мне удавалось обходиться лишь двумя хинтами - first_rows & cardinality. При том, оба эти хинта - хинты оптимизатора.

Добавлено @ 11:27

Следует учитывать что оптимизатор смотрит на значение при расчете селективности, только в сулчае, если это значение присутсвтует в гистограмме, в противном случае он принимает за селективность количество уникальных/ количество всего.
Как в этом случае будет оцениваться Null, мне не известно.
Вообще,я уже говорил что исползование null как значения - дурная практика, со всеми вытекающими. Null таки это "отсутствие значения"

Это сообщение отредактировал(а) Zloxa - 18.6.2009, 11:44

У Тома Кайта видел пример сканирования по индеку при условии is (not) null, при том что не осуществляется сбор статистики.
Он предлагает индексировать не колонку, а функцию:  nvl(НАЗВАНИЕ_КОЛОНКИ,АЛЬТЕРНАТИВНОЕ_ЗНАЧЕНИЕ) .
Я попробовал воспроизвести такой пример, но без дополнительной хинтовки, он всё равно делает селект без индекса:

Для твоего примера у меня индекс используется и без хинта и без статистики (10.2.0.3, 9.2.0.8).
Однако отбор - это отбор.

А ты вот попробуй join по FBI сделать 
У меня лично не получилось. Как грится хинтуй - не хинтуй, а в плане один .... )

Это сообщение отредактировал(а) Zloxa - 19.6.2009, 14:38

Гоню...
получилось ;)

10.2.0.4 - фул скан и ничего не могу поделать.

Добавлено @ 18:07

но если со статитикой , как  у тебя по джойну то получается ...

Это сообщение отредактировал(а) v2v - 19.6.2009, 18:07

я такое, если не ошибаюсь, поробовал раньше. При это в плане это разивается на два условия

nvl(child.par_id, -1) = par.id
or nvl(child.par_id, -1) =-1

но при этом все равно остается фулскан...



Это директивы или консольный вывод?

И вообще, где можно достать полезную информацию о механизмах планирования и оптимизации. Все, с чем я сталкивался до этого -  очень общие понятия (Оракл делает планы, и потом ими пользуется). Но при этом я не имею целостного представления о том, что, где и когда делает Оракл? Что, где и когда может анализировать разработчик, а также чем, где и когда он может пользоваться, чтоб работа всего этого механизма происходила эффективно ?


Спасибо!!!

Oracle® Database Performance Tuning Guide

ANALYZE


1)Индекс по функции при том строил?
2)Статистика по индексу,(таблице) после построения индекса собиралась?
3)Системная статистика вообще когданибудь собиралась?

4)Ты уверен в том что фуллскан МЕНЕЕ эффективен?
Случается, порой, я ПРИНУЖДАЮ ораклю использовать full scan, потому как дождаться результата при использовании индексного доступа - терпения не хватает. Ты упоминал ранее что селективность твоего запроса 18%. Это достаточно высокая селективность. На такой селективности я вполне могу поверить что фуллскан будет эффективнее. Все зависит от отношения стоимости операций ввода вывода к стоимости операций CPU. Может так статься что сотни многоблочных чтений с полной загрузкой ЦПУ будут выполняться много быстрее тысяч одноблочных чтений при низкой загурзке ЦПУ.

если ответы на вопросы 1,2,3,4 утвердительные, используй хинт INDEX, как это делает v2v в своем примере.


Это сообщение отредактировал(а) Zloxa - 23.6.2009, 14:35