Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Индексация поля [D6, IB6.x]

Страницы: < 1 2
Жук © (2005-07-05 13:34:00)
Имеет ли смысл в большой(по количеству записей)таблице делать индекс по полю, которое может принимать всего 6 значений? Есть ряд запросов, где в условиях встречается это поля. В итоге я в плане получаю БОЛЬШАЯТАБЛИЦА NATURAL.

ЮЮ (2005-07-06 03:40:00) [21]
И все-таки, почему бы не писать явно, что хочешь получить:

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)

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

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

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

Johnmen (2005-07-05 21:02:00) [23]
>Жук © (05.07.05 18:05) [12]

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

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

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

Desdechado (2005-07-05 18:31:00) [25]
[3]
битовые индексы в IB/FB, увы, пока недоступны
а так, самое для них место

Жук (2005-07-05 18:05:00) [26]
2 Johnmen ©
Блин, Евгений ! Я уж и не рад, что спросил :-)

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

Johnmen (2005-07-05 17:05:00) [27]
>Жук © (05.07.05 16:52) [10]

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

Жук (2005-07-05 16:52:00) [28]
Таблицы связаны по внешним ключам, по 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 16:23:00) [29]

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

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

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

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

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

Жук (2005-07-05 16:03:00) [31]
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 = БОЛЬШАЯТАБЛИЦА

Johnmen (2005-07-05 14:51:00) [32]
>Жук © (05.07.05 13:34)
>В итоге я в плане получаю БОЛЬШАЯТАБЛИЦА NATURAL.

Код давай.

Danilka (2005-07-05 14:45:00) [33]
jack128 © (05.07.05 14:41)
Если же это не единственное условие, то просто перестрой запрос так

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

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

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

Игорь Шевченко (2005-07-05 14:00:00) [35]
Теория говорит, что в ряде случаев имеет смысл сделать bitmapped-индексы.

dolmat (2005-07-05 13:40:00) [36]
Если оно фигурирует в операции выборки т.е. после where, group и т.п., то желательно это увеличит скорость выполнения запроса, а если только select, то нет необходимости.

Anatoly Podgoretsky (2005-07-05 13:38:00) [37]
Жук © (05.07.05 13:34)
Теория говорит НЕТ, неэффективно, и вероятнее всего план не будет использовать этот индекс.

Страницы: < 1 2

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »