Оптимизация запроса

← →
webpauk © (2007-11-06 11:50) [0]

with Query1 do begin SQL.Clear; SQL.Add("SELECT City.Name+" ["+Regions.Name+", "+Area.Name+"]" FROM City"); SQL.Add("INNER JOIN Area ON (City.IDArea=Area.ID)"); SQL.Add("INNER JOIN Regions ON (Area.IDRegion=Regions.ID)"); SQL.Add("WHERE"); SQL.Add("City.ID=25430"); Active:=true; end;

Объединяю базу городов с базами районов и областей.
Первоначально, как я понимаю, происходит JOIN по таблицам (очень долго), а потом выполняются условия.
Есть ли метод сделать наоборот (в одном запросе)

← →
ЮЮ © (2007-11-06 12:03) [1]

> Первоначально, как я понимаю, происходит JOIN по таблицам
> (очень долго),

Точно, что очень долго именно в окрытии Query1, а не в обработчиках?

> (в одном запросе)

попробуй
JOIN Area ON (City.ID=25430) AND (City.IDArea=Area.ID)
если подзапросы не поддерживаются.

З.Ы.
>"City.ID=25430"
а для остальных City.ID тоже код напишешь?

← →
webpauk © (2007-11-06 12:19) [2]

> >"City.ID=25430"
> а для остальных City.ID тоже код напишешь?

это для упрощения и наглядности вопроса

← →
Правильный_Вася (2007-11-06 12:21) [3]

индексы есть?

← →
webpauk © (2007-11-06 12:23) [4]

>
> Правильный_Вася (06.11.07 12:21) [3]

да есть вроде бы

← →
webpauk © (2007-11-06 12:23) [5]

> JOIN Area ON (City.ID=25430) AND (City.IDArea=Area.ID)

ускорило блин!!!!

← →
clickmaker © (2007-11-06 12:25) [6]

> как я понимаю, происходит JOIN по таблицам (очень долго),
>

JOIN - это еще не выборка фактически. Нормальный сервер сначала отберет записи из основной таблицы по условию в where, а потом уж начнет фактически по связке отбирать.

← →
webpauk © (2007-11-06 12:26) [7]

> clickmaker © (06.11.07 12:25) [6]

ага...
всё бы хорошо, только загрузка идет долго

← →
ЮЮ © (2007-11-06 12:32) [8]

> индексы есть?

в конкретном примере в JOIN и WHERE используются ключевые поля, индекс по которым всяко должен быть.
Но для чичтоты эксперимента можно попробовать создать индексы по City.IDArea и Area.IDRegion.

Я на MS SQL нарвался на тормоза при удалении при наличии ссылочной целостности и отсутсвии индексов по "справочным" полям.

← →
sniknik © (2007-11-06 13:27) [9]

> Я на MS SQL нарвался на тормоза при удалении при наличии ссылочной целостности и отсутсвии индексов по "справочным" полям.
"справочные" это те которые в "подчиненных" таблицах на которые внешний ключ ссылается?
тогда так и должно быть. (удаление из главной влечет за собой запрос на удаление из подчиненной по условию равенства значения ключа этому полю, а по нему индекса нет...)
или это вообще "левое" поле не участвующее в "отношениях по ссылочной целостности".
тогда это весьма странно.

← →
Johnmen © (2007-11-06 14:15) [10]

> clickmaker © (06.11.07 12:25) [6]
> JOIN - это еще не выборка фактически. Нормальный сервер
> сначала отберет записи из основной таблицы по условию в
> where, а потом уж начнет фактически по связке отбирать.

Нет. Сначала все JOIN"ы, потом WHERE. Ведь в WHERE могут быть совершенно разные условия про разные таблицы.

← →
clickmaker © (2007-11-06 14:43) [11]

> [10] Johnmen © (06.11.07 14:15)

да?
то есть, если я напишу
select c.Client_ID, c.Name, ct.Name as City from Client c
inner join City ct on c.City_ID = ct.City_ID
where c.ID in (1,4,67)

то он отберет все City.Name, а уже потом наложит where?

← →
sniknik © (2007-11-06 14:59) [12]

> то он отберет все City.Name, а уже потом наложит where?
сомневаюсь я в этом чтото... (сомнение касаются только MSSQL, для FB/DBISAMT хз. ;)
проверить бы надо. кто желает? :)

а вот если условие будет where ct.ID in (1,4,67), то так и будет.

> clickmaker © (06.11.07 14:43) [11]

Так и будет в общем случае. Когда оптимизатор не шибко продвинутый. Как видим для DBISAM это так.

> clickmaker © (06.11.07 14:43) [11]
> sniknik © (06.11.07 14:59) [12]

Проверить? Так автор уже проверил: см.[0] и [5].

← →
Правильный_Вася (2007-11-06 15:09) [14]

план запроса посмотреть слабо?

> Проверить? Так автор уже проверил: см.[0] и [5].
у него DBISAMTb, я не знаю что это такое и как работает. потому и написал "сомнение касаются только MSSQL, для FB/DBISAMT хз."
просто мне показалось, что у clickmaker-а вопрос более общего характера чем только для DBISAMTb.

> план запроса посмотреть слабо?
посмотри. будь ласка. ;)

> clickmaker (06.11.2007 14:43:11) [11]

Я бы не стал гадать про внутреннее устройство интерпритатора и построитель планов.

> sniknik (06.11.2007 14:59:12) [12]

Не сомневайся, оптимизатор в MSSQL хитрый и делает совсем не то, что логически кажется правильным программисту.
Оптимизатор это штука сама в себе, не обязательно, что два запроса подряд будут работать по одному плану, поскольку кроме оптимизатора еще существует и статистика.
И это я могу подтвердитью

> webpauk (06.11.2007 12:23:04) [4]

Понятие "вроде бы" не должно существовать в лексике программиста, иначе это далеко заведет.

Оптимизация запроса Найти похожие ветки