iBase.ru Forum

Есть запрос

select p.pers_id, p.fio, p.dcreate, p.tcreate,
g.pgruppa, d.department, o.doljnost, f.firma

from departments d, groups g, firms f, occupations o, personnel p

where (p.department_id = d.department_id) and
(p.pgruppa_id = g.pgruppa_id) and
(p.firma_id = f.firma_id) and
(p.doljnost_id = o.doljnost_id)

order by dcreate

Он выполняется достаточно заметное время (порядка 5 секунд).
Без части order by запрос выполняется мгновенно.

Если делать выборку только по главной таблице

select PERS_ID, FIO,dcreate,tcreate

from personnel p

order by dcreate

запрос выполняется мгновенно.

Индекс по полю dcreate и по всем полям для связи таблиц есть.

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

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

План запроса

Plan
PLAN SORT (JOIN (D NATURAL,P INDEX (DEPARTMENT_ID),O INDEX (OCCUPATIONS_ID),F INDEX (FIRMS_FIRMA_ID),G INDEX (GROUPS_PGRUPPA_ID)))

Adapted Plan
PLAN SORT (JOIN (D NATURAL,P INDEX (DEPARTMENT_ID),O INDEX (OCCUPATIONS_ID),F INDEX (FIRMS_FIRMA_ID),G INDEX (GROUPS_PGRUPPA_ID)))

Использую FB-1.0.2.

А что можно подкрутить и где?

g.pgruppa, d.department, o.doljnost, f.firma

эти поля случаем не varchar/char размером так по 1000 символов?

И сколько запрос выполняется без сортировки?

Случаем да, не то чтобы по 1000, но по 100, по 200 символов. Но запрос с этими полями, но без сортировки выполняется моментально (порядка 15 милисекунд).
Раньше все было в одной таблице, и проблем не было. Но решили сделать правильно и результат оказался плачевен...

сколько записей сортируется, и сколько времени это занимает?

bill_2000 писал(а):Случаем да, не то чтобы по 1000, но по 100, по 200 символов. Но запрос с этими полями, но без сортировки выполняется моментально (порядка 15 милисекунд).

Берём число записей в запросе и смотрим какой массив данных нужно отсортировать, особо учитыая суммарный размер записи в результирующем запросе - делаем ВЫВОДЫ.

Oleg Loa писал(а): Берём число записей в запросе и смотрим какой массив данных нужно отсортировать, особо учитыая суммарный размер записи в результирующем запросе - делаем ВЫВОДЫ.

Запрос с той же сортировкой только по главной таблице - происходит моментально, хотя количество записей то же. Когда поля department, firma и пр. находились в главной таблице, сортировка происходила моментально, хотя суммарный размер записи был примерно такой же.
Поэтому ВЫВОД мне пока не понятен.

проблема в том, что сервер решил проехаться натуралом по departments, а индекс order by есть только для персон. Соответственно, сортировка идет через память-диск, непонятно только, почему тебя напрягает пауза в 5 секунд.

Что забавно, все исправилось, когда я убрал индексы в главной таблице по идентификаторам словарных полей. Тут же исчез натурал, и выборка стала осуществляться за 15 милисекунд. Как бы это еще понять...