rdb_dev,

селективность - это 1/(Keys - TotalDup), где TotalDup - количество повторов ключей. Буквально Keys - TotalDup это количество уникальных значений в ключе (считается от 1 как +1 при каждом повторе значения ключа).
Допустим, 1000 записей.

все разные = 1/(1000 - 1) = 0,001001001
все одинаковые = 1/(1000 - 999) = 1
два значения = 1/(1000-998) = 0.5
и т.д.

То есть, селективность - показатель уникальности индекса.

rdb_devВедь, для любого значения индекса, одно значение индекса - одна строка таблицы.
ШТО? :-)

rdb_dev<отбираемое_кол-во_строк(среднее)> = <кол-во_строк_таблицы> * <селективность_индекса>
если ты про эффективность индекса с учетом его уникальности, то
- dimitr утверждает, что индекс остается эффективным (против натурала) даже если по индексу выбирается до 90% записей

- с точки зрения I/O это может быть не так. Например, таблица 762 мб. Если читать все натуралом, это столько и будет.
Следовательно, если использовать индекс для поиска 90% записей, индекс должен быть по размеру меньше этих самых 10% (или равен, в крайнем случае). 10% это 76.2мб. А вот я на этой таблице вижу индексы по 68мб, 88мб, 104 мб, 166мб.
Неуникальные все, как назло, как раз в районе 70мб :-) а вот уникальные - больше. Значит их эффективность должна быть ниже 90%.

- у нас нет гистограмм. Есть только Max Duplicates в статистике - это максимальное число повторов одного ключа.
Например. 1000 записей, 2 ключа. 1 ключ = 1 запись, 2й ключ - 999 записей. Селективность будет 0.5. И эффективность поиска по ключу 1 и ключу 2 будет очень разная - с ключом в 999 записей будут прочитаны почти все страницы индекса, т.е. I/O будет много выше.

Так что, твоя форула, как мне кажется, "ни о чем".
1000 * 0.5 = 500? А тут нет 500, тут есть или 1, или 999, которые оба весьма далеки от 500.

rdb_devДля случая, когда:
я еще попутно (на всякий случай) добавлю, что количество ключей плавает между количеством записей и количеством записей+версий.
Например, 1 запись со значением А в столбце. 1 ключ, указывающий на эту запись.
Теперь делаем update этой записи на значение Б
- запись одна
- версий две
- ключей два, оба указывают на одну и ту же запись.

rdb_devлибо одна запись, либо почти все. Но разве оно того не стоит?
все же, неплохо было бы иметь гистограммы. В реальных базах обычно много индексов с большим количеством дубликатов одного значения ключа. Оптимизатор сейчас такие индексы использует почти безусловно (кроме других критериев).
Поэтому Симонов и написал про +0 или ||''. Но в этом случае мы вынуждены писать разные запросы при выборке конкретных значений, что крайне неудобно.
rdb_devЕсли есть вероятность, что половина обращений по такому индексу будет приводить лишь к чтению только двух страниц таблицы
это уже зависит от предметной области. Вырожденный случай - FK с миллиона записей на справочник с одной записью. Индекс по ФК обязателен быть, но у него селективность = 1, т.к. всего 1 значение. Допустим, оптимизатор такой индекс не станет брать (хотя вроде берет).
Тут ты добавляешь в справочник еще одну запись, которая год-два (а может и никогда) использоваться не будет. Индекс получает селективность 0.5 (после обновления статистики), и ... получается что все равно он нафиг не нужен (оптимизатору).

rdb_dev,

визуально - +0. Потому что +0 это понятно, а cast через год-два уже и не вспомнишь, зачем писал.
По скорости - надо проверять.