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

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

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


делает выборку по таблице 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

Спаисбо за сылки!

1) - да. Разве что, я использовал выражение (как в индексе, так и в запросе) DECODE(FILED, null, 0, FILED). Это же не принципиально?
2) и 3) Скорей всего нет, если это не делается автоматически
4) Ничего не могу сказать вообще...

Т.е. буду читать теорию...
Только еще хочу уточнить, приведенные ссылки могут дать понимание на уровне



Или до этого еще очень далеко?

1) Нет, не принципиально.

4) Дык а попробовать? ))


Указанный уровень весьма абстрактен. )
Многие хвалят книгу Льюиса "Основы стоимостной оптимизации". Я читал лишь пару глав... (кста, надо найти и перечесть ). Кашу в мозгах сортирует хорошо. Но особого прозрения не ожидай, там лишь описано как, почему и на основе чего оптимизатор выбирает план. Однако что именно дает понимание этого, ясно весьма не сразу. ;) Понимание принципов работы оптимизатора приводит лишь к тому что начинаешь чаще соглашаться с результатами его работы 


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