Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
 select * from (select ....) ... оптимизация  [new]
hlopotun
Member

Откуда:
Сообщений: 673
Всем доброго дня,

разбираю сейчас проблемы с неиндексированными запросами в одном из проектов и столкнулся с запросами вида
select Table.A, Table.B, Table.D from (select * from Table where ....) where .... которые по идее переписываются без проблем как
select Table.A, Table.B, Table.D from Table where ....
Посколку явление это в этом проекте массовое и походу эти запросы генерируются фреймворком автоматически (этот вопрос я пока проясняю) возникает вопрос насколько такие запросы проблематичны. IBExpert при анализе их производительности показывает что всё в порядке и если есть задержки по причине отсутствия индексов при их создании они исчезают. Но у меня возникают сомнения на тему внутренней оптимизации таких запросов в FB (2.5.8)
вот пара примеров таких запросов:
+

select PO_STATUS from (select * from v_55_uebersicht v INNER JOIN (select distinct pro.proid as pid, u.id, u.username, u.isadmin 
from projekte pro LEFT JOIN prouserroles pur ON pro.proid=pur.proid RIGHT JOIN (select username, isadmin, id 
from v_85_zavuserroles where (username = 'SYSOP')) u ON u.ID = pur.userid or u.isadmin = 'T') 
roles ON cast (case when (v.proid is null) or (v.proid = 'min') then '{00000000-0000-0000-0000-000000000000}' 
else v.proid end as varchar (38)) = roles.pid) where (AUFTRID = '{0002152D-FBD7-45FA-9468-DD400F89CC7F}')

Plan
--------------------------------------------------------------------------------
PLAN SORT ((V TK_TECHORDERS INDEX (IDX_TK_TECHORDERS_UPDT)))
PLAN (V TK_TECHOBJECTS INDEX (RDB$FOREIGN25))
PLAN (V TK_SITEINFOS INDEX (IDX_TK_SITEINFOS_TO))
PLAN (V TK_SITEINFOS INDEX (IDX_TK_SITEINFOS_TO))
PLAN SORT ((V TK_PURCHASEORDERS INDEX (IDX_TK_PURCHASEORDERS_UPDT)))
PLAN MERGE (SORT (SORT (JOIN (JOIN (JOIN (ROLES U V_85_ZAVUSERROLES U INDEX (IDX_ZAVUSER_USERNAME), ROLES U V_85_ZAVUSERROLES RA INDEX (PKUSERROLES)), ROLES U V_85_ZAVUSERROLES RS INDEX (PKUSERROLES)), JOIN (ROLES PRO NATURAL, ROLES PUR INDEX (FK_PROUSERROLES_PRO))))), SORT (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (V A INDEX (RDB$PRIMARY4), V PRO INDEX (RDB$PRIMARY2)), V BL INDEX (RDB$PRIMARY17)), V BEARB INDEX (RDB$PRIMARY17)), V AUFMBEARB INDEX (RDB$PRIMARY17)), V TECHORD INDEX (RDB$PRIMARY22)), V TECHOBJ INDEX (RDB$PRIMARY24)), V SI_A INDEX (RDB$PRIMARY27)), V SI_B INDEX (RDB$PRIMARY27)), V POORD INDEX (RDB$PRIMARY30)), V B INDEX (RDB$PRIMARY4)), V SEN SE ORDER IDX_TK_SERVICEENTRIES_DTAG_ASC INDEX (IDX_TK_SERVICEENTRIES_DTAG_ASC))))

Adapted Plan
--------------------------------------------------------------------------------
PLAN SORT ((V TK_TECHORDERS INDEX (IDX_TK_TECHORDERS_UPDT)))
PLAN (V TK_TECHOBJECTS INDEX (INTEG_86))
PLAN (V TK_SITEINFOS INDEX (IDX_TK_SITEINFOS_TO))
PLAN (V TK_SITEINFOS INDEX (IDX_TK_SITEINFOS_TO))
PLAN SORT ((V TK_PURCHASEORDERS INDEX (IDX_TK_PURCHASEORDERS_UPDT)))
PLAN MERGE (SORT (SORT (JOIN (JOIN (JOIN (ROLES U V_85_ZAVUSERROLES U INDEX (IDX_ZAVUSER_USERNAME), ROLES U V_85_ZAVUSERROLES RA INDEX (PKUSERROLES)), ROLES U V_85_ZAVUSERROLES RS INDEX (PKUSERROLES)), JOIN (ROLES PRO NATURAL, ROLES PUR INDEX (FK_PROUSERROLES_PRO))))), SORT (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (V A INDEX (INTEG_12), V PRO INDEX (INTEG_6)), V BL INDEX (INTEG_57)), V BEARB INDEX (INTEG_57)), V AUFMBEARB INDEX (INTEG_57)), V TECHORD INDEX (INTEG_62)), V TECHOBJ INDEX (INTEG_64)), V SI_A INDEX (INTEG_67)), V SI_B INDEX (INTEG_67)), V POORD INDEX (INTEG_100)), V B INDEX (INTEG_12)), V SEN SE ORDER IDX_TK_SERVICEENTRIES_DTAG_ASC INDEX (IDX_TK_SERVICEENTRIES_DTAG_ASC))))

------ Performance info ------
Prepare time = 0ms
Execute time = 0ms
Avg fetch time = 0,00 ms
Current memory = 43.570.748
Max memory = 48.881.948
Memory buffers = 2.048
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 2.546

или

select LOGID, MSGID, REFTOMSGID, AUFTRID, DTAGVGID, BUYERTECHORDERID, OBJ_DESCRIPTION, OBJ_TIME, LCH_DATE, LCH_USER from (select * from WSObjLog) where ((DTAGVGID is null)) order by LOGID asc, AUFTRID asc


Plan
--------------------------------------------------------------------------------
PLAN SORT ((WSOBJLOG INDEX (IDX_WSOBJLOG_DTAGVGID)))

------ Performance info ------
Prepare time = 16ms
Execute time = 109ms
Avg fetch time = 7,27 ms
Current memory = 36.841.296
Max memory = 36.849.912
Memory buffers = 2.048
Reads from disk to cache = 15.269
Writes from cache to disk = 0
Fetches from cache = 75.342
2 ноя 21, 11:55    [22391293]     Ответить | Цитировать Сообщить модератору
 Re: select * from (select ....) ... оптимизация  [new]
hvlad
Member

Откуда:
Сообщений: 11551
hlopotun
Но у меня возникают сомнения на тему внутренней оптимизации таких запросов в FB (2.5.8)
Какие именно сомнения ? В чём проблема выполнить два запроса и сравнить время, планы, статистику ?
2 ноя 21, 12:27    [22391305]     Ответить | Цитировать Сообщить модератору
 Re: select * from (select ....) ... оптимизация  [new]
Ivan_Pisarevsky
Member

Откуда: НН
Сообщений: 8877
hlopotun
которые по идее переписываются без проблем как
Совершенно не факт, что от этого они станут оптимальнее.

hlopotun
вот пара примеров таких запросов:
первый запрос, на вой взгляд, написан в трудном для понимания стиле. Лично я бы его переписал на более удобоваримый.

Звездочки - зло независимо от.
2 ноя 21, 12:41    [22391312]     Ответить | Цитировать Сообщить модератору
 Re: select * from (select ....) ... оптимизация  [new]
hlopotun
Member

Откуда:
Сообщений: 673
hvlad
hlopotun
Но у меня возникают сомнения на тему внутренней оптимизации таких запросов в FB (2.5.8)
Какие именно сомнения ? В чём проблема выполнить два запроса и сравнить время, планы, статистику ?


в тех запросах что найду да, но поскольку фреймворк по видимому некоторые из них генерирует сам то интересен ответ на вопрос - в плане оптимизации, само по себе использование select ... from (select ...) порочно или нет для FB 2.5.8?
2 ноя 21, 13:11    [22391327]     Ответить | Цитировать Сообщить модератору
 Re: select * from (select ....) ... оптимизация  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 1119
hlopotun,

Запрос неудобоваримый для чтения. Его хотя бы отформатировать. Я вот очень часто использую "select ... from select ...". Превратить его в один select порой проблематично, поскольку нужно наложить два условия where, причём второе условие уже по "агрегатам". Можно переписать через CTE.
То что джойн к селекту тоже не криминал. Тоже через CTE можно попробовать.
2 ноя 21, 13:13    [22391328]     Ответить | Цитировать Сообщить модератору
 Re: select * from (select ....) ... оптимизация  [new]
hvlad
Member

Откуда:
Сообщений: 11551
hlopotun
в плане оптимизации, само по себе использование select ... from (select ...) порочно или нет для FB 2.5.8?
Если речь идёт о проталкивании предикатов во внутренний select, то это должно работать.
Или я не понимаю суть сомнений.
2 ноя 21, 13:17    [22391333]     Ответить | Цитировать Сообщить модератору
 Re: select * from (select ....) ... оптимизация  [new]
hlopotun
Member

Откуда:
Сообщений: 673
спасибо всем,
развеяли сомнения
4 ноя 21, 10:45    [22391867]     Ответить | Цитировать Сообщить модератору
Все форумы / Firebird, InterBase Ответить