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

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

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

Как заставить INTERBASE изменить план [D7, IB5.x, IB6.x]

Страницы: 1 2 >
den_777 © (2005-02-21 16:43:00)
Проблема в следующем. Предположим есть таблица со следующими полями
field1 integer,
field2 integer,
field3 integer,
field4 varchar(10),
field5 varchar(5),
field6 varchar(2),
field7 varchar(2)

создан индекс
CREATE INDEX IDX1 ON MYTBL(FIElD4,FIElD5,FIElD6,FIElD7);

Выполняется запрос
select distinct FIElD4,FIElD5,FIElD6,FIElD7 from MYTBL
И Intebase 5.6 и FireBird1.5.1 строят один и тот же план:
PLAN (MYTBL NATURAL)
а план подставленный вручную
PLAN ((MYTBL index (IDX1)))
пониматься не хочет.

Это так и заложено в идеологии баз с многоверсионностью записей или просто недоработка INTERBASE, ведь вся информация для моего запроса может быть извлечена из индекса, а INTEBASE никак не хочет этого делать.

den_777 (2005-02-21 18:29:00) [1]

> а ты поля в нужном порядке в order ставил, как в индексе?

а то(ну в смысле конечно), ладно предлагаю закончить дискуссию, потому как мне борльше было нужно не объяснение поведения INTERBASE, а возможный способ ускорения запроса. Как следует из дискусси и доп материалов, такого способа нет(или он мне еще неведом).

Desdechado (2005-02-21 18:20:00) [2]
а ты поля в нужном порядке в order ставил, как в индексе?

den_777 (2005-02-21 18:15:00) [3]

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

не будет, уже попробовал

Desdechado (2005-02-21 18:11:00) [4]
поставь Order by и будет тебе использование индекса, вот только зачем?

den_777 (2005-02-21 17:59:00) [5]

> Я не совсем понял, о каком данном поведении речь

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

Johnmen (2005-02-21 17:56:00) [6]
Я не совсем понял, о каком данном поведении речь, но про использование индекса там написано. При этом не важно, что он явно не указан в плане.

den_777 (2005-02-21 17:48:00) [7]

> Весь текст прочитай.

Извини. Может я туп или плохо понимаю английский, но перечитав внимательно еще раз, так и не понял на что мне следовало обратить внимание. Если не трудно можно указать конкретную фразу в этой статье, которая объясняет данное поведение INTERBASE, при select distinct по 4 полям и более.
С уважением.

Johnmen (2005-02-21 17:28:00) [8]
>den_777 (21.02.05 17:18) [14]

Весь текст прочитай.

den_777 (2005-02-21 17:19:00) [9]

> Как же это не всех, если нужны все ключи???

Наверное мы с тобой по разному понимаем как устроен индекс

den_777 (2005-02-21 17:18:00) [10]

> Johnmen © (21.02.05 17:07) [9]
> http://www.ibase.ru/mail/distindex.txt

So if you want to use an index to select "distinct a, b, c, d", you
should define an index on "a, b, c, d". If you define separate indexes
on each column, InterBase will use only the index on "a".

И в чем отличие от моего варианта.

> http://www.ibase.ru/ibfaq.htm#distinct

В том то и дело, что у меня IB5.6 а использованием индекса и не пахнет

Sergey13 (2005-02-21 17:16:00) [11]
2[3] den_777 (21.02.05 16:59)
> т.е когда в запросе перечислены только поля, которые входят в какие либо индексыпо этой таблице
Ну наверное не "в какие либо", а в индекс учавствующий в запросе.

Petr V. Abramov (2005-02-21 17:15:00) [12]
> наверняка можно придумать алгоритм с обходом не всех ветвей и элементов индекса
Как же это не всех, если нужны все ключи???

den_777 (2005-02-21 17:11:00) [13]

> Хотя в данном конкретном случае, IMHO, какой хитроумный
> алгоритм не используй, выигрыша сильного не будет

Это почему. Очень даже не очевидно. Любой индекс имеет древовидную структуру. Селективность индекса 0.03. На основе этих двух фактов наверняка можно придумать алгоритм с обходом не всех ветвей и элементов индекса. Это и будет намного быстрее.

Petr V. Abramov (2005-02-21 17:10:00) [14]
> select distinct вроде как сам собой напрашивается на испоьзование уникального индекса по этим полям
если индекс уникальный, зачем distinct ???

Johnmen (2005-02-21 17:07:00) [15]
http://www.ibase.ru/mail/distindex.txt
http://www.ibase.ru/ibfaq.htm#distinct

Petr V. Abramov (2005-02-21 17:06:00) [16]
> В реальной таблице 54 поля
Ну тогда да.
Но успокойте себя тем, что FB - халявный, а Informix дорого стоит. :)))

den_777 (2005-02-21 17:05:00) [17]
Скажу даже больше. Проэкспериментировал с похожей по струтуре таблицой, но в кторой можно сохдать уникальный индекс по 4 полям. select distinct вроде как сам собой напрашивается на испоьзование уникального индекса по этим полям . Но не тут то было, опять table full scan.

Petr V. Abramov (2005-02-21 17:03:00) [18]
Ну может, в Informix index full scan оптимизирован.
Хотя в данном конкретном случае, IMHO, какой хитроумный алгоритм не используй, выигрыша сильного не будет.
вот если б размер записи килобайт 100 был, тогда б имело смысл

den_777 (2005-02-21 17:02:00) [19]

> Ну что, что может. А с чего ты решил, index full scan будет
> быстрее table full scan, тем более индекс с таким размером
> ключа?

В реальной таблице 54 поля, и я почему-то думаю что index full scan был бы намного быстрее table full scan

Petr V. Abramov (2005-02-21 16:59:00) [20]
> ИБ вроде не умеет брать инфу из индекса.
Умеет. когда это имеет смысл :)

> ведь вся информация для моего запроса может быть извлечена из индекса
Ну что, что может. А с чего ты решил, index full scan будет быстрее table full scan, тем более индекс с таким размером ключа?

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

Наверх

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