Появилась такая задача, в которой необходимо выбирать из таблици oborot данные порядка 30000 тысяч раз с разными параметрами(аналитиками). Время работы хочется максимально уменьшить! Привожу исходник выборки
.Create view a1
as
select *
from oborot, spkau, SYNONYM spkau spkau1
where ((
word(127) == spkau.kodgrkau
and st_var == spkau.code
and word(10009) == spkau1.kodgrkau
and mvz_var == spkau1.code
and FDate<<= oborot.datob and LDate >>= oborot.datob
and 127 == oborot.tblos[1](noindex)
and spkau.nrec == oborot.kauos[1](noindex)
and 10009 == oborot.tblos[3](noindex)
and spkau1.nrec == oborot.kauos[3](noindex)
))
and oborot.kauos[3]<>000100000000733Dh
;
Изменяются st_vat и mvz_var, количество комбинаций порядка 30000.
Хочется чтобы использовались индексы по oborot.tblos[1] oborot.kauos[1] и oborot.tblos[3] oborot.kauos[3] но компилятор грит что нужен один составной индекс (oborot.datob oborot.datob oborot.tblos[1] oborot.kauos[1] oborot.tblos[3] oborot.kauos[3]).
Если несколько индексов одновременно нельзя использовать , то почему тогда на oborot.datob oborot.datob не ругается?
Можно ли использовать несколько индексов в одной выборке по одной таблице?
а не проще ли сначала выгрузить oborot без фильтров spkau,spkau1 (во врем.таблицу например) а потом уже убрать лишнее? При том вам при отборе можно будет проверить сначала 1 условие, и тока если оно выполняется, то 2.
Если объем oborot большой, то тяжковато Вам придется..тем более без vip
Таблицы схемы user можно посмотреть x$files.xf$loc2. Там уж сами выберите подходящую,если таковая имеется...
Bounds тут вряд ли поможет - все равно подходящий индекс нужен.
Но вот оптимизация по скорости тяжела будет. Если у Вас скуль версия галактики, то лучше перепишите отчет на TSQL
bounds то можно накладывать 2 и более- AddBounds. тока не всегда при это идет выйгрыш - 2 и последующий аналогичны условию (noindex). Но делать 30000 тысяч мелких запросов при смене условий к серверу уж точно не хорошо. Лучше один крупный(максимально оптимизированный) а потом лишнее отобрать. В сапорте напишите запрос- посмотрите скока будет записей. TMPGRN мне нравиться индексом TMPGRN01 - wlist задать какой нибудь нереальный типа 999 и усе - шансов пересечься будет мало. В первасиве можно по монитору посмотреть используется ли при типичной обстановке пользователя такая то табла схемы user.