вообщем такое дело
есть запрос:

Код

select i.suid, i.title_russian, w.suid w_suid  from   inventory i inner join wares w on(i.suid=w.uid_issue ) where  w.uid_section='MS-SEC-BOOKS' and  ( i.title_russian like('Ïß%') or i.title_english like('FA%') or i.title_translit like('DF%') or w.product_number like('A20%') ) order by i.suid

_все_ используемые поля - индексированы.
Статистика сброшена. (с ней или без нее - разницы в сути нет, см. далее).
колл-во селектируемых строк - около 85к

в табличках по ~350к записей в каждой.

если не ставить order by - время запроса + первых 10 фетчей - менее секунды.

индексы и данные живут в разных таблспейсах.

если-же поставить order by - план не сильно меняется (ну обрасляется сортировкой).
И тут начинается. запрос виснет на долго. совсем на долго.
По монитору в Ent. Manager Console - идут непрерывные чтения из именно таблспейса с данными. типа фул скан. Из индексного таблспейса при этом почти (ну в 100-200 раз) ничего не читается.

и как быть?

Навести статистику вряд-ли реально предлагать - пробовал и с ней. и с RULE и COST и с INDEX(INVENTORY, PK_INVENTORY) - ничего состояние дел не меняет.


В чем-же дело? что такого в запросе по _всем_ индексным полям во всех частях запроса при сортировку внуждает активно читать именно данные, а не индексы???
Спасибо!

Дак а ты что думал, что 85к записей за пару секудн отсортируются? Попытайся уменьшить получаемый набор данных.

Цитата

Дак а ты что думал, что 85к записей за пару секудн отсортируются?

Это вовсе не большой набор данных, на моей домашней машине select из таблицы в 100000 записей и fetch первых 20 идет 0,47 сек, в этом запросе время конечно больше будет но не минуты же.

Посмотри в v$sql сколько чтений физических и логических производится для запроса с order by и без него.

Это сообщение отредактировал(а) LSD - 6.11.2005, 00:56