SQLRU.net
Разработка приложений баз данных

Начало » Использование СУБД » Firebird, HQbird, InterBase » Выполнение запроса очень тормозится на объединении
Выполнение запроса очень тормозится на объединении [сообщение #1594] Sun, 12 February 2023 13:42 Переход к следующему сообщению
Konstantin-78 в настоящее время не в онлайне  Konstantin-78
Сообщений: 4
Зарегистрирован: January 2023
Junior Member
Есть запрос

select
eq.ID, …, c_CALIBRATION_INTERVAL
 from EQUIPMENT eq
 left join LABORATORY l on l.id = eq.EQUIPMENT_LABORATORY_ID
 left join LABORATORY ld on ld.id = eq.LABORATORY_DOC_ID
 left join CERTIFICATE c on c.DEVICE_ID_CL = eq.ID
 and c.DISPLAY = 1 
  left join USERS_DATA u on u.ID = eq.EQUIPMENT_PARENT_USER_ID
  left join USERS_DATA ud on ud.ID = eq.USER_DOC_ID
    where eq.ARCHIVE in (1)
  and (((eq.CONTROL_MIN_DATE < '06.02.2023' and not eq.CONTROL_MIN_DATE is null)  or (eq.CONTROL_MIN_DATE is null and eq.COUNT_CERT <> -1)  or (eq.CONTROL_MIN_DATE is null and eq.COUNT_CERT >= 0)  or (eq.COUNT_CERT_REQUIRE <> eq.COUNT_CERT))
  and ((eq.CONTROL_MIN_DATE < '06.02.2023' and not eq.CONTROL_MIN_DATE is null)  or (eq.CONTROL_MIN_DATE is null and eq.COUNT_CERT <> -1)  or (eq.CONTROL_MIN_DATE is null and eq.COUNT_CERT >= 0)  or (eq.COUNT_CERT_REQUIRE <> eq.COUNT_CERT)))
  and ((c.CONTROL = 1 and eq.PASSPORT = 0) or ((c.CONTROL is null or c.CONTROL=1) and eq.PASSPORT = 1))
  order by eq.EQUIPMENT_PARENT_USER_ID, eq.NAME, eq.TYPE, eq.NUMBER, eq.NEMBER_INVENTORY
, но он работал чуть не правильно и пришлось его дополнить подзапросом, который я запихнул в VIEW:

CREATE OR ALTER VIEW V_CERTIFICATE_SIGNAL(
    DEVICE_ID_CL,
    CERTIFICATE_ID)
AS
select gr0.DEVICE_ID_CL, (case when gr1.id is null then gr0.id else gr1.id end) as CERTIFICATE_ID
  from (select max(c.ID) as ID, c.DEVICE_ID_CL
          from CERTIFICATE c
            where c.CONTROL = 1
              group by c.DEVICE_ID_CL) gr0
  left join (select c.id, c.DEVICE_ID_CL
               from CERTIFICATE c
                 where c.CONTROL = 1 and c."DISPLAY" = 1) gr1 on gr0.DEVICE_ID_CL = gr1.DEVICE_ID_CL    ;
Оба представленных запроса по отдельности работают быстро. Но когда я объединил первый запрос с VIEW, он начал очень сильно тормозить

select
eq.ID, eq.NAME,  eq.CONTROL_MIN_DATE, eq."TYPE", eq.NUMBER, eq.NEMBER_INVENTORY, eq.PRODUCER, eq.YEAR_BEGIN, eq.NAME_TEST, eq.REMARK, eq.USER_ID,  eq.DEPARTMENT_ID, eq.TIME_EDIT,
 eq.ARCHIVE, eq.SPECIFICATION, eq.DEVICE_DEPARTMENT_ID, eq.TYPE_SERIES, eq.DISLOCATION, eq.TYPE_EQUIP, eq.PASSPORT, eq.WARNING,  eq.EQUIPMENT_LABORATORY_ID, eq.COUNT_CERT_REQUIRE,
 eq.CONTROL_MIN_DOC,  eq.EQUIPMENT_PARENT_USER_ID, eq.COUNT_CERT, l.NAME_SHORT as l_NAME_SHORT_LAB,   eq.LABORATORY_DOC_ID, eq.FIND_TALLY, eq.DISLOCATION_ORG, eq.USER_DOC_ID,
 u.FULL_NAME as u_EQUIPMENT_USER, ld.NAME_SHORT as l_LABORATORY_DOC, ud.FULL_NAME as u_USER_DOC
, (case when c.NUMBER_CERT = '-1' then '' else c.NUMBER_CERT end) as c_NUMBER_CERT,  c.DATE_OPERATION as c_DATE_OPERATION, c.CALIBRATION_INTERVAL as c_CALIBRATION_INTERVAL
 from EQUIPMENT eq
 left join LABORATORY l on l.id = eq.EQUIPMENT_LABORATORY_ID
 left join LABORATORY ld on ld.id = eq.LABORATORY_DOC_ID
 left join V_CERTIFICATE_SIGNAL vcs on vcs.DEVICE_ID_CL = eq.ID   -- "VIEW"
 left join CERTIFICATE c on vcs.CERTIFICATE_ID = c.ID
  left join USERS_DATA u on u.ID = eq.EQUIPMENT_PARENT_USER_ID
  left join USERS_DATA ud on ud.ID = eq.USER_DOC_ID
    where eq.ARCHIVE in (1)
  and (((eq.CONTROL_MIN_DATE < '07.02.2023' and not eq.CONTROL_MIN_DATE is null)  or (eq.CONTROL_MIN_DATE is null and eq.COUNT_CERT <> -1)  or (eq.CONTROL_MIN_DATE is null and eq.COUNT_CERT >= 0)  or (eq.COUNT_CERT_REQUIRE <> eq.COUNT_CERT))
  and ((eq.CONTROL_MIN_DATE < '07.02.2023' and not eq.CONTROL_MIN_DATE is null)  or (eq.CONTROL_MIN_DATE is null and eq.COUNT_CERT <> -1)  or (eq.CONTROL_MIN_DATE is null and eq.COUNT_CERT >= 0)  or (eq.COUNT_CERT_REQUIRE <> eq.COUNT_CERT)))
  and ((c.CONTROL = 1 and eq.PASSPORT = 0) or ((c.CONTROL is null or c.CONTROL=1) and eq.PASSPORT = 1))
  order by eq.EQUIPMENT_PARENT_USER_ID, eq.NAME, eq.TYPE, eq.NUMBER, eq.NEMBER_INVENTORY
где-то 30 секунд выбирает 94 записи из возможных 344
Чуть поэкспериментировав, т.е. представил результат VIEW, в виде обычной таблицы, и подставив ее вместо VIEW, все прошло быстро и без тормозов.


Что можно посмотреть и куда копать, чтоб ускорить запрос с использованием VIEW? Заранее спасибо.

[Обновления: Sun, 12 February 2023 14:40]

Известить модератора

Re: Выполнение запроса очень тормозится на объединении [сообщение #1595 является ответом на сообщение #1594] Sun, 12 February 2023 15:23 Переход к предыдущему сообщениюПереход к следующему сообщению
SD в настоящее время не в онлайне  SD
Сообщений: 407
Зарегистрирован: August 2022
Senior Member
Смотреть в план. Копать в https://www.ibase.ru/dataaccesspaths/
Re: Выполнение запроса очень тормозится на объединении [сообщение #1596 является ответом на сообщение #1594] Sun, 12 February 2023 18:08 Переход к предыдущему сообщениюПереход к следующему сообщению
sim_84 в настоящее время не в онлайне  sim_84
Сообщений: 329
Зарегистрирован: June 2022
Senior Member
Для начала надо бы перестать бездумно фигачить left join везде. Ибо в отличие от ineer join. он практически не оптимизируется
Re: Выполнение запроса очень тормозится на объединении [сообщение #1597 является ответом на сообщение #1596] Sun, 12 February 2023 19:24 Переход к предыдущему сообщениюПереход к следующему сообщению
kdv в настоящее время не в онлайне  kdv
Сообщений: 98
Зарегистрирован: June 2022
Member
Кроме того неплохо бы посмотреть
https://youtu.be/0KITHwMNDtw
и второе видео с ответами на вопросы.

Так-то, "объединение запроса с view" это просто два объединенных запроса. Представьте, что view не существует. Оно именно так и работает. view не дает никакого выигрыша в производительности, просто "скрывает" часть запроса.
Кроме того, select max с группировкой, join с select, как бы намекают, что в запросе таблицы объединяются как попало, а с учетом left join уже сказали, всё идет строго по порядку.
Re: Выполнение запроса очень тормозится на объединении [сообщение #1598 является ответом на сообщение #1597] Sun, 12 February 2023 23:40 Переход к предыдущему сообщениюПереход к следующему сообщению
МП в настоящее время не в онлайне  МП
Сообщений: 887
Зарегистрирован: August 2022
Географическое положение: бурятский тун...
Senior Member
Да чо уж там.
Давай сразу в Тик-ток!
Re: Выполнение запроса очень тормозится на объединении [сообщение #1599 является ответом на сообщение #1598] Mon, 13 February 2023 01:01 Переход к предыдущему сообщениюПереход к следующему сообщению
Старый Плюшев в настоящее время не в онлайне  Старый Плюшев
Сообщений: 95
Зарегистрирован: August 2022
Географическое положение: Ленинград
Member
МП писал(а) Sun, 12 February 2023 23:40
Да чо уж там.
Давай сразу в Тик-ток!
Боюсь тут даже это не поможет.
Re: Выполнение запроса очень тормозится на объединении [сообщение #1600 является ответом на сообщение #1599] Mon, 13 February 2023 13:23 Переход к предыдущему сообщениюПереход к следующему сообщению
Konstantin-78 в настоящее время не в онлайне  Konstantin-78
Сообщений: 4
Зарегистрирован: January 2023
Junior Member
вместо VIEW, нужно было использовать хранимую процедуру - и сразу заработало шустро (ну это кому интересно)
Re: Выполнение запроса очень тормозится на объединении [сообщение #1601 является ответом на сообщение #1600] Mon, 13 February 2023 13:41 Переход к предыдущему сообщению
МП в настоящее время не в онлайне  МП
Сообщений: 887
Зарегистрирован: August 2022
Географическое положение: бурятский тун...
Senior Member
Konstantin-78 писал(а) Mon, 13 February 2023 13:23
вместо VIEW, нужно было использовать хранимую процедуру - и сразу заработало шустро (ну это кому интересно)
мы не видим планов, не видим DDL.
мы слышим стук в подвале.
и шо бы ты хотел?!
Предыдущая тема: Firebird 4.0.2 "уходит в себя" при завершении работы клиентского приложения
Следующая тема: Проблема при работе с полями типа GUID в FibPlus через Variant
Переход к форуму:
  


Текущее время: Fri Nov 15 07:09:15 GMT+3 2024

Общее время, затраченное на создание страницы: 0.01245 секунд