Индексация поля

← →
Жук © (2005-07-05 13:34) [0]

Имеет ли смысл в большой(по количеству записей)таблице делать индекс по полю, которое может принимать всего 6 значений? Есть ряд запросов, где в условиях встречается это поля. В итоге я в плане получаю БОЛЬШАЯТАБЛИЦА NATURAL.

← →
Anatoly Podgoretsky © (2005-07-05 13:38) [1]

Жук © (05.07.05 13:34)
Теория говорит НЕТ, неэффективно, и вероятнее всего план не будет использовать этот индекс.

← →
dolmat (2005-07-05 13:40) [2]

Если оно фигурирует в операции выборки т.е. после where, group и т.п., то желательно это увеличит скорость выполнения запроса, а если только select, то нет необходимости.

← →
Игорь Шевченко © (2005-07-05 14:00) [3]

Теория говорит, что в ряде случаев имеет смысл сделать bitmapped-индексы.

← →
jack128 © (2005-07-05 14:41) [4]

Жук © (05.07.05 13:34)
Есть ряд запросов, где в условиях встречается это поля
встречается ТОЛЬКО это поле ? то есть в результате этого запроса у нас выползет 1/6 БОЛЬШОЙ ТАБЛИЦЫ ? а зачем юзеру так нужны эти 100000 записей ???

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

← →
Danilka © (2005-07-05 14:45) [5]

jack128 © (05.07.05 14:41)
Если же это не единственное условие, то просто перестрой запрос так

или использовать составные индексы по двум и более полям

← →
Johnmen © (2005-07-05 14:51) [6]

>Жук © (05.07.05 13:34)
>В итоге я в плане получаю БОЛЬШАЯТАБЛИЦА NATURAL.

Код давай.

← →
Жук © (2005-07-05 16:03) [7]

select v.smena, sum(t.metrag)
from virabbr v, vir_bra b, vir_bra_tel t
where v.id=b.id_vir and b.id=t.id_vir_bra and
v.ondate between ?ondate1 and ?ondate2
and t.id_sort_enum=?sort
group by v.smena

Выбираем по сменам метражи определённого сорта за какой-то период. Сортов - 6 штук. t = БОЛЬШАЯТАБЛИЦА

← →
alex_*** (2005-07-05 16:07) [8]

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

← →
Johnmen © (2005-07-05 16:23) [9]

> alex_*** (05.07.05 16:07) [8]
> еще можно заморочиться по поводу кластеризованных/некластеризованных
> индексов...

Не можно. И не нужно.

>Жук © (05.07.05 16:03) [7]

Почему не весь код ?
Приводи индексы, план запроса, др. на своё усмотрение...

← →
Жук © (2005-07-05 16:52) [10]

Таблицы связаны по внешним ключам, по VIRABBR.ondate - индекс.

Plan:
PLAN SORT (JOIN (T NATURAL,B INDEX (RDB$PRIMARY40),V INDEX (RDB$PRIMARY39,VIRABBR_IDX1)))

Adapted plan:
PLAN SORT (JOIN (T NATURAL,B INDEX (PK_VIR_BRA),V INDEX (PK_VIRABBR,VIRABBR_IDX1)))

← →
Johnmen © (2005-07-05 17:05) [11]

>Жук © (05.07.05 16:52) [10]

Связи, связи... Как связаны то ?
Почему тянуть из тебя надо ?

← →
Жук © (2005-07-05 18:05) [12]

2 Johnmen ©
Блин, Евгений ! Я уж и не рад, что спросил :-)

3 таблицы связаны внешними ключами так, как прописано во where, соответственно и индексы есть по этим полям (примари кей и форейн кей) тут всё ясно. Далее: отбор идёт за период, в этой таблице VIRABBR - индекс по дате есть.
Но самая нижняя таблица vir_bra_tel грозит очень разрастись, а запросы, типа того, что я привёл, будут использоваться в отчётах.
Пока база пустая, не могу понять нужно мне рисовать индекс по полю сортности (6 штук) или не надо.
Можно, конечно сразу отсечь ненужную часть верхней таблицы по дате, а потом джойнами увязать, но и тогда всё будет зависеть от периода. Ведь, если он будет достаточно большим, то vir_bra_tel NATURAL всё равно будет напрягать.

← →
Desdechado © (2005-07-05 18:31) [13]

[3]
битовые индексы в IB/FB, увы, пока недоступны
а так, самое для них место

← →
Anatoly Podgoretsky © (2005-07-05 19:02) [14]

Жук © (05.07.05 18:05) [12]
В следующий раз будешь приходить подготовленым. Что то эта фраза мне напоминает. :-)

← →
Johnmen © (2005-07-05 21:02) [15]

>Жук © (05.07.05 18:05) [12]

Поздно нерадоваться, ты уже попался :)

Итак.
Экспериментируй. Во-первых, порядок лог.выражений в where, потом - индекс на то самое поле, потом - явные JOIN"ы, потом - порядок джоинов...
Потом будем думать :)

← →
Petr V. Abramov © (2005-07-05 22:11) [16]

> Игорь Шевченко © (05.07.05 14:00) [3]
> Теория говорит, что в ряде случаев имеет смысл сделать bitmapped-индексы.
В "IB6.x"???

> Жук © (05.07.05 13:34)
> В итоге я в плане получаю БОЛЬШАЯТАБЛИЦА NATURAL.
Не совсем дурной оптимизатор...

← →
ЮЮ © (2005-07-06 03:40) [17]

И все-таки, почему бы не писать явно, что хочешь получить:

select
v.smena, sum(t.metrag)
from
virabbr v
JOIN vir_bra b ON v.id=b.id_vir
JOIN vir_bra_tel t ON b.id=t.id_vir_bra
where
(v.ondate between ?ondate1 and ?ondate2) and
(t.id_sort_enum=?sort)
group by v.smena

Вместо того, чтобы оптимизатор приводил к виду

select
v.smena, sum(t.metrag)
from
vir_bra_tel t
JOIN ON b.id=t.id_vir_bra
JOIN virabbr v ON v.id=b.id_vir
where
(t.id_sort_enum=?sort) and
(v.ondate between ?ondate1 and ?ondate2)

Кстати, может быть запрос получается такой из-за того, что Пока база пустая?

← →
Игорь Шевченко © (2005-07-06 11:36) [18]

Petr V. Abramov © (05.07.05 22:11) [16]

Теория ведь не только к IB относится, верно ? Хотя, признаюсь честно, упоминание об IB я не разглядел сразу.

← →
Petr V. Abramov © (2005-07-06 13:17) [19]

> Теория ведь не только к IB относится, верно ?
Почти :)
Bitmap-индекс имеет смысл, если есть несколько полей, каждое из которых принимает малое количество различных значений.

← →
Игорь Шевченко © (2005-07-06 13:23) [20]

> Bitmap-индекс имеет смысл, если есть несколько полей, каждое
> из которых принимает малое количество различных значений.

То есть, по одному полю делать битмап-индекс смысла нет ? :)
А пачему ?

← →
Petr V. Abramov © (2005-07-06 13:38) [21]

> Игорь Шевченко © (06.07.05 13:23) [20]
> А пачему ?
Ну как тебе сказать... :)
Суть битмапа в том, что одно поле принимает мало разных значений, а комбинаций значений в нескольких полях уже имеющее смысл количество

← →
Игорь Шевченко © (2005-07-06 13:52) [22]

Petr V. Abramov © (06.07.05 13:38) [21]

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

А я-то дурак думал, что можно несколько значений одного поля указывать, и СУБД будет выполнять конъюнкцию или дизъюнкцию точно так же, как и в случае нескольких полей...

← →
Petr V. Abramov © (2005-07-06 14:03) [23]

> Игорь Шевченко © (06.07.05 13:52) [22]
Ну может, дурак я :). Тем более что давно этим не занимался.
Но давай подойдем к этому так: ты в чудеса веришь? Если различных значений мало, какие ты конъюнкции с дизъюнкциями ни делай, это будет выгодней full table scan?

> и СУБД будет выполнять конъюнкцию или дизъюнкцию точно так же,
> как и в случае нескольких полей...
чего с чем конъюнкцию или дизъюнкцию?

← →
Игорь Шевченко © (2005-07-06 14:13) [24]

> чего с чем конъюнкцию или дизъюнкцию?

Наборов битов, разумеется. Ведь битовые индексы как работают - у тебя есть битовая строка, каждый бит в которой соответствует номеру записи для данного значения ключа.
Так вот, для того, чтобы оценить количество записей, в которых ключевому полю соответствует данное значение, достточно посчитать количество единичных битов в индексе, для того, чтобы определить, в каких записях содержится одно или другое значение, достаточно взять две битовые строки (для каждого значения) и выполнить над ними операцию дизъюнкции (логического или) - в результирующей битовой строке каждому биту соотвествует нужная запись.

← →
Petr V. Abramov © (2005-07-06 14:24) [25]

> Игорь Шевченко © (06.07.05 14:13) [24]
> каждый бит в которой соответствует номеру записи для данного значения ключа.
Как бит может соответствовать номеру??? Таблицу из двух записей не рассматириваем :)

← →
Petr V. Abramov © (2005-07-06 14:36) [26]

Заставил-таки документацию посмотреть :)
Но смысл битового индекса по одному полю-то все равно - где? Только в одном случае - если значения распределены очень неравномерно, иначе fts опять будет выгоднее, т.к. чудес не бывает. А в этом случае и битмап городить необязательно.
А когда запрос идет по нескольким полям с малым количеством разных значений, вот тут и начинаются битовые операции.

Petr V. Abramov © (06.07.05 14:36) [26]

> А когда запрос идет по нескольким полям с малым количеством
> разных значений

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

Хотя может иметь смысл при ситуации типа 1000 значений на 50 миллионов записей.

> Игорь Шевченко © (06.07.05 14:54) [27]
> в запросах выборки количества записей с одним значением
тогда да

> или в выборке множества записей, удовлетворяющих
> критерию "одно значение" или "другое значение"
А в этом случае смысл какой??? кроме ситуации [28]

Petr V. Abramov © (06.07.05 14:58) [29]

> А в этом случае смысл какой???

Вот у тебя есть таблица с миллионом записей. В таблице поля "имя", "должность", "зарплата".

Должность распределена более или менее равномерна, допустим 8 значений. По этому полю сделан битовый индекс. Тебе надо найти среднюю зарплату для сотрудников, у которых должность "должность один" или "должность два". В этом случае индекс тебе выберет все нужные записи всяко быстрее, чем полный просмотр.

> Игорь Шевченко © (06.07.05 15:18) [30]
> В этом случае индекс тебе выберет все нужные записи всяко
> быстрее, чем полный просмотр.
Или медленнее :) Манипуляции с индексом + выборка сравнимы с последовательным чтением 3/4 таблицы, да еще в обход кэша.

Petr V. Abramov © (06.07.05 15:25) [31]

> Манипуляции с индексом + выборка сравнимы с последовательным
> чтением 3/4 таблицы, да еще в обход кэша

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

По результатам эксперимента на выборке одной пятой с кривым расперделением по даже локальному партиционированному битмапу разницы просто нет: +- 2%
Соотношение 6зн/4млн записей, партиционированная таблица (ессно, по другому полю).

Petr V. Abramov © (06.07.05 16:39) [33]

"Как физик доказывает, что все нечетные числа простые? Возьмем любое нечетное число. Единицу можно считать простым числом, 3, 5, 7 – простые. Досадно, что 9 – не простое число. Однако 11 и 13 – снова простые. Вернемся к числу 9, говорит физик. Я заключаю, что оно является ошибкой эксперимента."

А эта...Том Кайт кстати весьма подробно пишет, для чего и как нужны эти индексы...

Может, он немного не про то пишет, что ты пытаешься доказать? :)
"Оно, конечно, Александр Македонский герой, но зачем же стулья ломать?" :)
Хорошо, давай какую-нить базу и init-файл от нее, я тебе сделаю хоть битмап быстрее, хоть fts, во столько раз, сколько бутылок пива поставишь :)

Petr V. Abramov © (06.07.05 17:04) [35]

> Может, он немного не про то пишет, что ты пытаешься доказать

Я пытаюсь доказать, что битмап-индекс может быть полезен даже по одному полю. Ты с этим споришь ?

> Игорь Шевченко © (06.07.05 17:07) [36]
> Я пытаюсь доказать, что битмап-индекс может быть полезен даже
> по одному полю. Ты с этим споришь ?

- Является ли ваучер ценной бумагой?
- В жизни каждого человека хоть раз возникает такой момент, когда любая бумага является ценной!

Индексация поля Найти похожие ветки