Oracle - снова индексы

[Recoilme]

Селективность = 1/(Keys - TotalDup), где
Keys: Число ключей в индексе. Обычно равно Records в таблице
TotalDup: Всего повторений ключей. Чем ближе это число к Keys, тем менее эффективен данный индекс при поиске, особенно когда оптимизатор использует несколько индексов.

[Bars]

Цитата:

Сообщение от Recoilme

Селективность = 1/(Keys - TotalDup), где
Keys: Число ключей в индексе. Обычно равно Records в таблице
TotalDup: Всего повторений ключей. Чем ближе это число к Keys, тем менее эффективен данный индекс при поиске, особенно когда оптимизатор использует несколько индексов.

спасибо за объяснение

[Recoilme]

Цитата:

Сообщение от Bars

спасибо за объяснение

Попробуя сформулировать своими словами:
есть таблица 1
есть поле1, число, все значения в поле =1 - такой индекс будет бесполезен вообще
есть поле2, логика, тут индекс тоже будет бесполезен, т.к. обладает низкой слективностью, он делит таблицу примерно на 2 части, мало "селективит" и оптимизатор его проигнорирует
есть поле3, например дата - если большинство дат в таблице разные - индекс будет хорошим, потому что из миллиона записей он позволит отобрать 100 при условии по определенной дате

С составными индексами - сложнее - там сам плохо понимаю

Примерно так. СУБД считает селективность, примерно по той формуле что я привел, как точно считает оракл надо глядеть в доках. Там может быть ещё ряд условий, например макс кол дубликатов в индексе и т.п. На основании селективности оптимизатор решает свалиться в скан или юзать индекс. Процесс рассчета селективности называется сбор статистики, собрать её db ещё давно советовал.

Бывают ещё всякие причины не юзанья индекса. Например в версионных базах данных КАУНТ не использует индекс постольку-поскольку там идеология другая. Считаются "живые" версии записей, о кот. нет инфы в индексе, поэтому там фуллскан всегда и каунт тормозней чем в блокировочниках. Но т.к. оракл наполовину блокировочник, наполовину версионник как там работает каунт - сложно сказать. Есть ещё всякие фьючерс чтоб обмануть оптимизатор и заставить его НЕ пользовать индекс, например where a = b, заменяют на a+0=b

Бывает наоборот когда приложение посылает оптимизатору хинты заставляющие его использовать индекс даже если он неоптимален. Об этом я писал тут вначале.

Уфф устал. Вобщем гораздо толковей и лучше всё это написано тут: www.sql.ru, www.ibase.ru