Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Оптимизация запроса [D6, DBISAMTb]

webpauk © (2007-11-06 11:50:00)
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 по таблицам (очень долго), а потом выполняются условия.
Есть ли метод сделать наоборот (в одном запросе)

Anatoly Podgoretsky (2007-11-06 19:17:00) [1]
> webpauk (06.11.2007 12:23:04) [4]

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

Anatoly Podgoretsky (2007-11-06 19:16:00) [2]
> sniknik (06.11.2007 14:59:12) [12]

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

Anatoly Podgoretsky (2007-11-06 19:14:00) [3]
> clickmaker (06.11.2007 14:43:11) [11]

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

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

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

Правильный_Вася (2007-11-06 15:09:00) [5]
план запроса посмотреть слабо?

Johnmen (2007-11-06 15:07:00) [6]

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

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

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

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

sniknik (2007-11-06 14:59:00) [7]
> то он отберет все City.Name, а уже потом наложит where?
сомневаюсь я в этом чтото... (сомнение касаются только MSSQL, для FB/DBISAMT хз. ;)
проверить бы надо. кто желает? :)

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

clickmaker (2007-11-06 14:43:00) [8]

> [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?

Johnmen (2007-11-06 14:15:00) [9]

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

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

sniknik (2007-11-06 13:27:00) [10]
> Я на MS SQL нарвался на тормоза при удалении при наличии ссылочной целостности и отсутсвии индексов по "справочным" полям.
"справочные" это те которые в "подчиненных" таблицах на которые внешний ключ ссылается?
тогда так и должно быть. (удаление из главной влечет за собой запрос на удаление из подчиненной по условию равенства значения ключа этому полю, а по нему индекса нет...)
или это вообще "левое" поле не участвующее в "отношениях по ссылочной целостности".
тогда это весьма странно.

ЮЮ (2007-11-06 12:32:00) [11]
> индексы есть?

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

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

webpauk (2007-11-06 12:26:00) [12]

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

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

clickmaker (2007-11-06 12:25:00) [13]

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

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

webpauk (2007-11-06 12:23:00) [14]

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

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

webpauk (2007-11-06 12:23:00) [15]

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

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

Правильный_Вася (2007-11-06 12:21:00) [16]
индексы есть?

webpauk (2007-11-06 12:19:00) [17]

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

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

ЮЮ (2007-11-06 12:03:00) [18]
> Первоначально, как я понимаю, происходит JOIN по таблицам
> (очень долго),

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

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

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

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »