> [19] Кщд   (02.11.09 12:38)
> ещё раз: при отсутствии null-значений полей - искать нечего
> - различных значений просто не будет

Вот и вернётся 0 записей.

Наткнулся на интересную особенность.
Oracle использует INDEX FAST FULL SCAN без доступа к таблице даже при запросе вида
.
Причем на запросах вида select count(PK_NAME) может использовать НЕ индекс по полю PK_NAME, а индекс по другому not null полю. А если есть bitmap index, то использует его, даже если этот индекс построен по полю nullable.

stakan   (03.11.09 14:15) [21]


> Oracle использует INDEX FAST FULL SCAN без доступа к таблице
> даже при запросе вида select count(*).


Если по списку предикатов определяется, что достаточно сканировать индекс. В противном случае будут сканироваться данные.

Льюис на эту тему достаточно подробно пишет, в "Основах стоимостной оптимизации"

>stakan   (03.11.09 14:15) [21]
Oracle использует тот метод доступа, который является более подходящим - согласно ли правилам или собранной статистике(RBO и CBO, соответственно, - что у вас там?) - поэтому четкие утверждения о том, что всегда используется Index FFS, безосновательны.
С BI индексом - тоже всё ясно, т.к. он содержит null-значения, в отличие от B-tree индекса Oracle.
Собирайте статистику и не ищите магию.

> Oracle использует тот метод доступа, который является более
> подходящим - согласно ли правилам или собранной статистике(RBO
> и CBO, соответственно, - что у вас там?) - поэтому четкие
> утверждения о том, что всегда используется Index FFS, безосновательны.
>
> С BI индексом - тоже всё ясно, т.к. он содержит null-значения,
>  в отличие от B-tree индекса Oracle.
> Собирайте статистику и не ищите магию.
>

Да это все понятно и логично, никакой магии нет. И то что
> всегда используется Index FFS
я не утверждал.
 Просто приятно удивила догадливость оптимизатора. Честно говоря, думал, что при запросах
оптимизатор выберет table scan.

>stakan   (04.11.09 12:20) [24]
>Просто приятно удивила догадливость оптимизатора. Честно говоря, думал, что >при запросах select count(*) from t оптимизатор выберет table scan.
хуже, когда догадливость переходит в "догадливость" для сложных запросов
тогда приходится стабилизировать план вручную

Кщд   (04.11.09 13:47) [25]


> тогда приходится стабилизировать план вручную


Или чаще собирать статистику :)

> stakan  (04.11.2009 12:20:24)  [24]

В данном виде возмодно просто укажет количество записей, которое ему уже известно, без обращения к таблице или индексам.

>Игорь Шевченко ©   (04.11.09 14:08) [26]
на некоторых старых системах это невозможно, т.к. сбор статистики жестко ударит по производительности, ввиду того, что разлетятся планы
а ресурсов на переписывание системы просто нет...
есть и второй аспект: иногда(особенно на сложных запросах), оптимизатор так забавно, простите, оптимизирует, что результаты запроса с нестабилизированным планом в худшую сторону(т.е. попросту бредовые) отличаются от явно прохинтованных - наверняка с таким встречались?
это случается крайне редко и, конечно, вовсе не повод не собирать статистику или вставлять хинты куда  ни попадя
имеется и третий аспект проблемы: во внутренних представлениях Oracle до сих пор можно встретить /*+ rule*/(тяжелое наследие индийской культуры) - поэтому в таких случаях, очевидно, собранная статистика не спасет

Кщд   (04.11.09 15:09) [28]


> наверняка с таким встречались?


Безусловно. Лечилось изменением запроса и следованием мантре "оптимизатор всегда прав" (он в 99,9% оказывается прав). Я стараюсь использовать хинты как можно реже, потому что без хинтов план запроса будет более оптимально подстраиваться под данные.


> во внутренних представлениях Oracle до сих пор можно встретить
> /*+ rule*/(тяжелое наследие индийской культуры)


Это не тяжелое наследие индийской культуры, это очень разумное положение: работает - не трогай. Если для чего-то гарантировано известно, что по правилам будет работать быстро и надежно, то пусть работает по правилам. В конце концов сам оптимизатор по правилам гораздо быстрее отрабатывает фазу подготовки запроса к исполнению.


> сбор статистики жестко ударит по производительности


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

>Игорь Шевченко ©   (04.11.09 16:04) [29]
>Безусловно. Лечилось изменением запроса и следованием мантре >"оптимизатор всегда прав" (он в 99,9% оказывается прав).
на боевой системе изменение запроса не всегда возможно: элементарно нет понимания, какие данные должен вернуть запрос с точки зрения бизнеса, а знание это давно утеряно, т.к. разработчик уволился, постановщик болеет, а заказчик почил в бозе
но проследить логику, заложенную разработчиком и заставить oracle делать именно то, что от него хотели - можно

>Я стараюсь использовать хинты как можно реже, потому что без хинтов план запроса будет более оптимально подстраиваться под данные.
абсолютно согласен

>Это не тяжелое наследие индийской культуры, это очень разумное >положение: работает - не трогай
не согласен: ядро эволюционирует, но костыли остаются - это неправильно
правило "работает - не трогай" работает для прикладных систем - спора нет, но такой подход ужасен в СУБД
сбор статистики обязательно полезен был бы и для словаря данных, но - увы - вероятно, нет ресурсов на переписывание груды индийского кода
явное хинтование rule'ом в ядре - это костыль и признание немощности разработчиком
табу на сбор статистики в SYS - это ли не бред?)

>Сбор статистики еще сам по себе занимает ресурсы, что тоже не >положительно сказывается на производительности.
здесь можно лавировать технологическими перерывами и параметрами сбора статистики, но когда мы на стенде сделали сбор статистики на древней системе, перенесенной на 10g, испытали ужас и потрясение

> перенесенной на 10g

На 10-ке еще баги выплыли. Некоторые сильно усложняют жизнь.

>ANB   (06.11.09 13:01) [31]
сильно осложняют особенно те, которые латать в 10-ке и не собираются)
впрочем, надежды скачать 10.2.0.5 не оставляю
подождем 11.2 и будем кочевать - как обычно

Есть еще один нюанс.
Предположим, что на какой-то столбец в таблице наложили ограничение по доступности - не доступен для чтения.
Тогда SELECT count(*) не отработает, как и не отработает запрос
SELECT COUNT(1)

>salexn   (09.11.09 12:57) [33]
отличный нюанс - главное, подходящий для всех СУБД