очень медленно работает запрос....

← →
yk © (2005-04-14 13:16) [0]

Уважаемые Мастера!
Помогите пожалуйста с запросом (очень медленно работает и выдаёт не то что надо).

Что у меня есть:
Есть таблицы:
1. таблица сборок
SBORKI (
IDSBORKA INTEGER NOT NULL ,
OBOZNACH VARCHAR(50) NOT NULL ,
NAIMENOVAN VARCHAR(50) NOT NULL ,
REV VARCHAR(20) ,
ISPOLN VARCHAR(20) ,
IDSBORKASTATUS INTEGER NOT NULL ,
IDEDIZM INTEGER NOT NULL ,
IDPROIZVODITEL INTEGER NOT NULL ,
PRIMECH VARCHAR(50) ,
IDPRIMLEVEL INTEGER NOT NULL
);
Индекс (OBOZNACH,NAIMENOVAN,REV,ISPOLN,IDSBORKASTATUS)
2. таблица связей между сборками (сборки могут включать друг друга. типа как вложенные папки)
IERHLINK (
IDIERHLINK INTEGER NOT NULL ,
IDSBORKAPARENT INTEGER NOT NULL ,
IDSBORKACHILD INTEGER NOT NULL ,
COUNTS INTEGER NOT NULL ,
POS VARCHAR(20) NOT NULL
);
Индекс (IDSBORKAPARENT,IDSBORKACHILD,POS)
3. Представление QSborki
VIEW QSBORKI(
IDSBORKA,
OBOZNACH,
NAIMENOVAN,
REV,
ISPOLN,
IDSBORKASTATUS,
SBORKASTATUSNAIMENOVAN,
IDEDIZM,
EDIZMNAIMENOVAN,
IDPROIZVODITEL,
PROIZVODITELNAIMENOVAN,
PRIMECH,
IDPRIMLEVEL,
PRIMLEVELNAIMENOVAN)
AS
SELECT Sborki.IdSborka,
Sborki.Oboznach,
Sborki.Naimenovan,
Sborki.Rev,
Sborki.Ispoln,
Sborki.IdSborkaStatus,
SborkaStatus.Naimenovan,
sborki.idedizm,
EdIzm.naimenovan,//из справочной таблицы
sborki.idproizvoditel,//из справочной таблицы
proizvoditel.naimenovan,//из справочной таблицы
Sborki.Primech,
Sborki.idprimlevel,
PrimLevel.naimenovan //из справочной таблицы
FROM Sborki, SborkaStatus, EdIzm,proizvoditel,PrimLevel
WHERE SborkaStatus.IdSborkaStatus=Sborki.IdSborkaStatus and
EdIzm.idedizm=sborki.idedizm and
Proizvoditel.idproizvoditel=sborki.idproizvoditel and
PrimLevel.idprimlevel=sborki.idprimlevel
;

В таблице Sborki 580 записей, в ierhlink 4500
В справочных таблицах примерно 10-20 записей
QSborki естественно 580.

Есть запрос
SELECT IdSborka, Oboznach, Naimenovan, Rev, Ispoln, SborkaStatusNaimenovan, Primech
FROM QSborki
WHERE
idSborkaStatus=4 and
not(exists (Select * from IerhLink where IerhLink.IdSborkaChild=QSborki.IdSborka))
Order by QSborki.Naimenovan

Требуется: Выбрать все сборки, которые не входят в другие сборки.

В результате:
Запрос работает долго - секунд 20, записи выбираются не все

ПОМОГИТЕ ПОЖАЛУЙСТА!

← →
P.N.P. © (2005-04-14 13:23) [1]

Ужасть.
Sborki, SborkaStatus, EdIzm,proizvoditel,PrimLevel ключами связаны?
Индексы какие-то есть по полям
SborkaStatus.IdSborkaStatus,
Sborki.IdSborkaStatus,
EdIzm.idedizm,
sborki.idedizm,
Proizvoditel.idproizvoditel,
sborki.idproizvoditel,
PrimLevel.idprimlevel,
sborki.idprimlevel?
План запроса можно посмотреть?

← →
DSKalugin © (2005-04-14 13:28) [2]

Каааароче, проиндексируй сначала ключевые поля в таблицах-справочниках.
И может быть те, по которым происходит связывание таблиц

← →
Ольга (2005-04-14 16:13) [3]

Может конструкция not in здесь больше подходит:
SELECT IdSborka, Oboznach, Naimenovan, Rev, Ispoln, SborkaStatusNaimenovan, Primech
FROM QSborki
WHERE
idSborkaStatus=4 and
IdSborka not in (Select IerhLink.IdSborkaChild from IerhLink ...)

← →
P.N.P. © (2005-04-14 16:22) [4]

>Ольга (14.04.05 16:13) [3]
>Может конструкция not in
Проверено, FireBird тормозит при использовании IN (select...)
Так что лучше not exists

← →
Fay © (2005-04-14 23:36) [5]

DSKalugin © (14.04.05 13:28) [2]
Это очень свежая мысль - проиндексировать ключевые поля. Ключевые - это какие?

← →
Fay © (2005-04-14 23:38) [6]

P.N.P. © (14.04.05 16:22) [4]
Про FB не скажу, но в IB был баг: запрос в IN (...) выполнялся для каждой записи.

← →
ЮЮ © (2005-04-15 03:17) [7]

>Fay © (14.04.05 23:38) [6]

Почему это глюк, если в подзапрос исользуется поле из основной таьлмцы. Или наше дело написаьб абы как, а оптимизатор приаедет текст запроса к нужноиу виду? Почему сразу не сделать JOIN таблмц?

SELECT
IdSborka, Oboznach, Naimenovan, Rev, Ispoln,
SborkaStatusNaimenovan, Primech
FROM
QSborki
LEFT JOIN IerhLink ON IerhLink.IdSborkaChild=QSborki.IdSborka
WHERE
(idSborkaStatus = 4) and (IerhLink.Id IS NULL)
Order by QSborki.Naimenovan

← →
yk © (2005-04-15 09:34) [8]

Forieng key нет вообще
все связи на триггерах

← →
P.N.P. © (2005-04-15 09:46) [9]

>yk © (15.04.05 09:34) [8]
>все связи на триггерах
Это как это?

← →
Виктор © (2005-04-15 10:38) [10]

Во первых 20 сек для такого плана запроса немного,
а во вторых если и этого мало тогда советую наставить индексов на поля по которым выбирается вхождение:
>Требуется: Выбрать все сборки, которые не входят в другие сборки.
я так понимаю это IDSBORKA.
И стоит попробовать совет >Ольга (14.04.05 16:13) [3]

← →
ЮЮ © (2005-04-16 11:19) [11]

>Во первых 20 сек для такого плана запроса немного

Ну-ну. Для таблицы из 580 записей? Да вручную в гриде выбрать быстрее :)
Попробуй [7], не пожалеешь !

Извините, если поздно отвечаю,
но [7] работает не на много быстрее :(

1. Нет индексов на поля связи.
2. Вместо * укажи 0 в not(exists (Select * from
3. Там же поменяй местами условия, связанные по and"у

Итог:

SELECT IdSborka, Oboznach, Naimenovan, Rev, Ispoln, SborkaStatusNaimenovan, Primech FROM QSborki LEFT JOIN IerhLink ON IerhLink.IdSborkaChild=QSborki.IdSborka WHERE (IerhLink.IdSborkaChild IS NULL) and (idSborkaStatus = 4) Order by QSborki.Naimenovan

работает достаточно долго 15 сек, учитывая что в таблице Sborki 560 записей, в ierhlink 4400 , а в остальных не более 30

Индекс (IDSBORKAPARENT,IDSBORKACHILD,POS)
на Qsborki нет индекса - это view

1. Заведи индекс (IDSBORKACHILD)
2. Связка с View даже в Oracle не есть круто (было раз, начальник велел сделать запрос в связке с View, работал минут 5, потом я сам экспериментально оставил только нужные таблицы и стал выолняться за 0.02 с)
3. Повесь FK по честному, иначе серверу труднее план строить, придется хинтовать.
4. Для такого количества записей это слишком долго даже для full scan, это странно.

← →
AlexO (2005-04-29 17:22) [16]

Добавь во view еще одно поле ChildCount типа
(select Count(*) from IerhLink where IerhLink.IdSborkaChild = SBORKI.IDSBORKA)

Тогда запрос упростится:
SELECT
IdSborka, Oboznach, Naimenovan, Rev, Ispoln,
SborkaStatusNaimenovan, Primech
FROM QSborki
WHERE (idSborkaStatus = 4) and (childCount is NULL)
Order by QSborki.Naimenovan

очень медленно работает запрос.... Найти похожие ветки