ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / составной запрос
11 сообщений из 36, страница 2 из 2
  2  все
составной запрос
    #38611056
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
anpl,

Код: sql
1.
2.
3.
4.
5.
select cl.surname, cl.phone
from season s
join clientseason cs on cs.seasonid = s.seasonid
join client cl on cl.clientid = cs.clientid
where s.typeseason = 'студенческий 8'



а если вот так? мне кажется тут дело не в left/inner а в том что s.typeseason = 'студенческий 8' в условие соединения воткнуто
...
Рейтинг: 0 / 0
10.04.2014, 12:41:02
| Ответить | Цитировать | Написать  
составной запрос
    #38611064
anpl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
anpl
Участник
Тут дело в том что смотря в какой таблице будет больше всего данных! в 90% случаях первый селект будет выполнятся быстрей...
но если в таблице season будет мало строк, а остальные таблицы будут тяжелые (пару миллионов строк) то скорость выполнения будет одинаковой.
А по логике во втором запросе сначала джойнится вся таблица clientseason и client с season а потом только отсекается лишнее, в первом варианте отсекается все лишнее а потом идет джоин
...
Рейтинг: 0 / 0
10.04.2014, 12:46:01
| Ответить | Цитировать | Написать  
составной запрос
    #38611070
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m7m
Участник
anplпервый план на
Код: sql
1.
2.
3.
4.
5.
select cl.surname, cl.phone
from season s
left join clientseason cs on cs.seasonid = s.seasonid
left join client cl on cl.clientid = cs.clientid
where s.typeseason = 'студенческий 8'


второй
Код: sql
1.
2.
3.
4.
select surname, phone
from client c
    join clientseason cs on c.clientid = cs.clientid
    join season s on (cs.seasonid = s.seasonid) and (s.typeseason = 'студенческий 8')



японский бог,
мой первый ответ был на 15860270
там лефтом и не пахнет
а когда отвечал на это 15860427 то на запросы просто не обратил внимания
...
Рейтинг: 0 / 0
10.04.2014, 12:48:18
| Ответить | Цитировать | Написать  
составной запрос
    #38611080
m7m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
m7m
Участник
Симонов Денисanpl,

Код: sql
1.
2.
3.
4.
5.
select cl.surname, cl.phone
from season s
  join clientseason cs on cs.seasonid = s.seasonid
  join client cl on cl.clientid = cs.clientid
where s.typeseason = 'студенческий 8'



а если вот так? мне кажется тут дело не в left/inner а в том что s.typeseason = 'студенческий 8' в условие соединения воткнуто

и вот так
Код: sql
1.
2.
3.
4.
select surname, phone
from client c
    join clientseason cs on c.clientid = cs.clientid
    join season s on (cs.seasonid = s.seasonid) and (s.typeseason = 'студенческий 8')



То время планы и время выполнения должны быть одинаковые
...
Рейтинг: 0 / 0
10.04.2014, 12:54:26
| Ответить | Цитировать | Написать  
составной запрос
    #38611082
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
anpl,

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

Plan
PLAN JOIN (CL NATURAL, CS INDEX (RDB$FOREIGN59), S INDEX (RDB$PRIMARY23))

не может быть от запроса

Код: sql
1.
2.
3.
4.
select surname, phone
from client c
    join clientseason cs on c.clientid = cs.clientid
    join season s on (cs.seasonid = s.seasonid) and (s.typeseason = 'студенческий 8')



т.к. в нём нет таблицы с алиасом CL
...
Рейтинг: 0 / 0
10.04.2014, 12:56:35
| Ответить | Цитировать | Написать  
составной запрос
    #38611089
anpl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
anpl
Участник
Симонов Денисanpl,

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

Plan
PLAN JOIN (CL NATURAL, CS INDEX (RDB$FOREIGN59), S INDEX (RDB$PRIMARY23))

не может быть от запроса

Код: sql
1.
2.
3.
4.
select surname, phone
from client c
    join clientseason cs on c.clientid = cs.clientid
    join season s on (cs.seasonid = s.seasonid) and (s.typeseason = 'студенческий 8')



т.к. в нём нет таблицы с алиасом CL

Код: sql
1.
2.
3.
4.
select сl.*
from client cl
 join clientseason cs on cl.clientid = cs.clientid
    join season s on (cs.seasonid = s.seasonid) and (s.typeseason = 'студенческий 8')


вот так выглядел селект
Ладно не хочу спорить! Что вам мешает сейчас взять и сделать подобные селекты?

По поводу
Код: sql
1.
2.
3.
4.
5.
select cl.surname, cl.phone
from season s
  join clientseason cs on cs.seasonid = s.seasonid
  join client cl on cl.clientid = cs.clientid
where s.typeseason = 'студенческий 8'


Plan
PLAN JOIN (CL NATURAL, CS INDEX (RDB$FOREIGN59), S INDEX (RDB$PRIMARY23))

Adapted Plan
PLAN JOIN (CL NATURAL, CS INDEX (FK_CLIENT_CLIENTSEASON_CLIENTID), S INDEX (INTEG_52))

------ Performance info ------
Prepare time = 0ms
Execute time = 609ms
Avg fetch time = 304,50 ms
Current memory = 10 562 264
Max memory = 18 250 804
Memory buffers = 256
Reads from disk to cache = 3 356
Writes from cache to disk = 0
Fetches from cache = 226 301
...
Рейтинг: 0 / 0
10.04.2014, 13:06:36
| Ответить | Цитировать | Написать  
составной запрос
    #38611131
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
anpl,

у меня цель не спорить. Если оптимизатор не понимает чего-то, то его надо научить, т.е. необходимо разобраться почему так и возможно написать тикет в трекер.

Что касается последнего запроса, то я вот не понимаю почему оптимизатор не стал применять индекс SEASON_TYPESEASON и сам не догадался что дешевле будет зайти с таблицы season s.

Единственная пока догадка что значения в этом поле распределены слишком неравномерно, т.е. большинство записей typeseason <> 'студенческий 8', но при этом равны какому-то другому значению многократно повторяющемуся. Таким образом, индекс имеет плохую селективность, а гистограммы значений пока не поддерживаются.
...
Рейтинг: 0 / 0
10.04.2014, 13:27:00
| Ответить | Цитировать | Написать  
составной запрос
    #38611175
anpl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
anpl
Участник
Симонов Денисanpl,

у меня цель не спорить. Если оптимизатор не понимает чего-то, то его надо научить, т.е. необходимо разобраться почему так и возможно написать тикет в трекер.

Что касается последнего запроса, то я вот не понимаю почему оптимизатор не стал применять индекс SEASON_TYPESEASON и сам не догадался что дешевле будет зайти с таблицы season s.

Единственная пока догадка что значения в этом поле распределены слишком неравномерно, т.е. большинство записей typeseason <> 'студенческий 8', но при этом равны какому-то другому значению многократно повторяющемуся. Таким образом, индекс имеет плохую селективность, а гистограммы значений пока не поддерживаются.
вы правильно рассуждаете...
в таблице SEASON 100к записей и только одна 'студенческий 8' и
в clientseason 10 записей в client 30
Я выше упоминал... что огромное значение имеет размеры каждой из таблиц...
...
Рейтинг: 0 / 0
10.04.2014, 13:40:59
| Ответить | Цитировать | Написать  
составной запрос
    #38611189
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
anpl,

дело не в размерах, а в равномерности распределений значений TYPESEASON. В большинстве случаев оптимизатор сам способен выбрать порядок соединения таблиц учитывая их размер и селективность индексов.

http://www.ibase.ru/devinfo/dataaccesspaths.htm
...
Рейтинг: 0 / 0
10.04.2014, 13:47:10
| Ответить | Цитировать | Написать  
составной запрос
    #38611190
anpl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
anpl
Участник
в clientseason 10 записей в client 30
извиняюсь... дезинформировал
в clientseason 30 строк в client 10 строк
...
Рейтинг: 0 / 0
10.04.2014, 13:47:32
| Ответить | Цитировать | Написать  
составной запрос
    #38611193
anpl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
anpl
Участник
Симонов Денисanpl,

дело не в размерах, а в равномерности распределений значений TYPESEASON. В большинстве случаев оптимизатор сам способен выбрать порядок соединения таблиц учитывая их размер и селективность индексов.

http://www.ibase.ru/devinfo/dataaccesspaths.htm
Не поверите! именно эта ссылка у меня уже минут 10 открыта )
...
Рейтинг: 0 / 0
10.04.2014, 13:49:17
| Ответить | Цитировать | Написать  
11 сообщений из 36, страница 2 из 2
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / составной запрос
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38611190&tid=1563716]:
 0ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 216ms
get topic data:
 23ms
get forum data:
 2ms
get page messages:
 81ms
get tp. blocked users:
 2ms
others: 250ms
total:  601ms
созд. / загр.: 601ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]