|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
Доброго! БД FB SS 2.1.7. (поменять не могу - это сервер пользователя) Сервер и клиент Win10 Prof Есть запрос выбираются некоторые карточки изделий из таблицы изделий. Есть таблица операций для каждого изделия. В таблице операций признаком, что операция еще не выполнялась является отсутствие даты закрытия операции. Мне нужно выбрать карточки изделий по некоторым параметрам, и у тех которые имеют не завершенные операции указать количество этих не завершенных операций. Пробовал по всякому, подзапрос в запросе, джойнить подзапрос к основному запросу (поскольку не все изделия имеют не завершенные операции то тут соединял по ЛЕФТ), создавал вьювер и джойнил к вьюверу, создавал временную таблицу и пытался залить туда агрегированные значения (вообще не вариант, более 20 минут идет запись в таблицу)... Пытался делать запрос в виде Execute block Бегу по выбранным изделиям и во внутреннем запросе отбираю подзапрос для данного изделия (ну это скорее уже от безисходности )))) Если из запроса убрать все справочники, то он примет вид Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
Вот реальный запрс Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
На картинке план запроса из IBE. (приношу извинения не разобрался как вставить картинку в нужное место) [img=] Вариант с джойном Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Результат тот же В общем проблема следующая в таблице операций более 4 миллионов записей. Запрос выполняется приемлимо около 2сек (запрс не оч. частый поэтому выполняется практически на "холодную". На горячую порядка 25мс), однако ФЕТЧ все сводит на нет. При выборке (среднее колмчество отбираемое основным запросом) около 4000 записей фетч идет где то около 30 сек. Может есть какой то другой способ подсоединить агрегированные данные из одной таблицы к другой? Спасибо. З.Ы. Сильно не пинайте, искал по форуму, ничего не нашел. Если где то кто то помнит что есть такая тема или похожая ткните носом. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 14:50 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
гуманоид, посторонний вопрос - а на таблицах что, первичных и вторичных ключей вообще нет??? кроме того, зачем "картинка с планом", если план запроса вы можете вынуть текстом из IBE после prepare запроса? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 15:51 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
CREATE UNIQUE INDEX NUM0 ON CARDNUMBER (CODECARDNUMBER); CREATE INDEX CARDNUMBER_IDX1 ON CARDNUMBER (CARDNUM); CREATE INDEX CARDNUMBER_IDX2 ON CARDNUMBER (CODERAZMER); CREATE INDEX CARDNUMBER_IDX3 ON CARDNUMBER (CODECOLORR); CREATE INDEX CARDNUMBER_IDX4 ON CARDNUMBER (CODEMODEL); CREATE INDEX CARDNUMBER_IDX5 ON CARDNUMBER (CODEZAKAZ); CREATE INDEX CARDNUMBER_ZAKAZDETAILED ON CARDNUMBER (CODEZAKAZDETAILED); CREATE UNIQUE INDEX OPERATIONCARD_IDX1 ON OPERATIONCARD (CODEOPERATIONCARD); CREATE INDEX OPERATIONCARD_IDX2 ON OPERATIONCARD (CODECARDNUMBER); CREATE INDEX OPERATIONCARD_IDX3 ON OPERATIONCARD (NUMBERPERSON); CREATE INDEX OPERATIONCARD_IDX4 ON OPERATIONCARD (CODEOPERATIONMODEL); CREATE INDEX OPERATIONCARD_IDX5 ON OPERATIONCARD (ETAP); CREATE INDEX OPERATIONCARD_IDX6 ON OPERATIONCARD (DATE_CLOSE); CREATE INDEX OPERATIONCARD_IDX7 ON OPERATIONCARD (NUMBEROPERATION); ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 16:04 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
kdv, Ну вот по CTRL+F9 план запроса к первому варианту Plan PLAN (OPERATIONCARD INDEX (OPERATIONCARD_IDX2, OPERATIONCARD_IDX6)) PLAN SORT (JOIN (RECEIPTS INDEX (RECEIPTS_IDX4), CARDNUMBER INDEX (NUM0), RAZMER INDEX (RAZMER0), COLORR INDEX (COLORR0), ZAKAZ INDEX (ZAKAZ0), CLIENT INDEX (CLIENT0), MODEL INDEX (MODEL0))) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 16:21 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
гуманоид, извиняюсь, а ЧТО ЭТО? база создавалась во времена царя Гороха, или разработчик не знал про ПК и ФК? Это вообще все индексы? На других таблицах никаких индексов нет? Это вопрос почти риторический, я не предлагаю тут вываливать метаданные. Просто вот есть таблица RAZMER. И на ней что, индексов нет вообще? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 16:45 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
Сколько времени занимает выполнение запроса без агрегата (с полным фетчем!) ? Изменился ли план запроса в этом случае ? Если тормозит таки агрегат, то для начала я бы (хинтом) отключил индекс по OPERATIONCARD.DATE_CLOSE. Или создал бы композит по CODECARDNUMBER, DATE_CLOSE. PS Алиасы к таблицам - это хорошо и правильно, но когда они совпадают с именами таблиц - глупо и не нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 17:01 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
kdv, Да база создавалась в InterBase, "до революции при немцах", когда еще ФБ даже не был в проекте. Вот состав базы и диалект там еще старый. (На картинке.) Вопрос не в том что это устарело, а в том можно ли его заставить работать шустрее. hvlad, Проверенно, тормозит именно агрегат. Вот в таком виде Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Запрос выполняется 600мс фетчится полностью - мгновенно ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 17:12 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
гуманоидДа база создавалась в InterBase, "до революции при немцах" да что вы говорите. в Interbase 4 в 1995 году были стандартные primary/foreign key. И при чем тут FB? Короче, по уму надо - все индексы, имитирующие ПК и ФК убить - создать нормальные ПК и ФК НА ВСЕХ таблицах - после чего запрос повторить. теоретически, агрегат этот ускорить никак не получится, надо его превратить в хранимый вместо вычисляемого. Тогда сильно полегчает. А так - нахрена постоянно count/group by базу долбать, непонятно. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 17:19 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
гуманоид Запрос выполняется 600мс фетчится полностью - мгновенно Отвечайте на все вопросы или не отвечайте вообще, уважайте чужое время. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 17:44 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
Попробую индексы переделать. Извините за непонятливость авторнадо его превратить в хранимый вместо вычисляемого. Имеется в виду ввести поле в таблицу куда помещать результат count или можно создать ХП и ее джойнить к запросу, хотя это тоже вычислимое выходит? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 17:45 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
hvlad, Прошу прощения. Вот план от этого запроса Plan PLAN SORT (JOIN (RECEIPTS INDEX (RECEIPTS_IDX4), CARDNUMBER INDEX (NUM0), RAZMER INDEX (RAZMER0), COLORR INDEX (COLORR0), ZAKAZ INDEX (ZAKAZ0), CLIENT INDEX (CLIENT0), MODEL INDEX (MODEL0))) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 17:46 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
hvlad, авторЕсли тормозит таки агрегат, то для начала я бы (хинтом) отключил индекс по OPERATIONCARD.DATE_CLOSE. Или создал бы композит по CODECARDNUMBER, DATE_CLOSE. Попробую чуть позже. Сейчас вынужден отлучиться. Спасибо за помощь. А да, композит по DATE_CLOSE "рассыпет " выборку на множество записей изделий по разным датам закрытия операций. Это не вариант. Создавал такой во вьювере. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
В выборке нужна одна запись с количеством не закрытых операций. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 17:49 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
гуманоид А да, композит по DATE_CLOSE "рассыпет " выборку на множество записей изделий по разным датам закрытия операций. Это не вариан ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 19:41 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
гуманоидИмеется в виду ввести поле в таблицу куда помещать результат count или можно создать ХП и ее джойнить к запросу, хотя это тоже вычислимое выходит? Не процедуру, спаси господи, это будет то же самое, только "сбоку". Насчет хранимого агрегата - смотрите, у вас сейчас там 4 миллиона записей, и "тормозит". Завтра, через месяц, через год у вас будет 10 миллионов записей (допустим), и тормозить будет еще больше. Зачем постоянно считать одно и то же? сделайте таблицу, в которой будут вот эти самые агрегированные значения. Пересчитывать их можно процедурой, чем угодно, периодически, с нужным интервалом. Например, в бухгалтериях так всегда делается - типа "закрытие месяца" - считаются данные за месяц, и сохраняются, чтобы их потом не считать каждый раз снова. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 20:17 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
kdv гуманоидИмеется в виду ввести поле в таблицу куда помещать результат count или можно создать ХП и ее джойнить к запросу, хотя это тоже вычислимое выходит? Не процедуру, спаси господи, это будет то же самое, только "сбоку". Насчет хранимого агрегата - смотрите, у вас сейчас там 4 миллиона записей, и "тормозит". Завтра, через месяц, через год у вас будет 10 миллионов записей (допустим), и тормозить будет еще больше. Зачем постоянно считать одно и то же? сделайте таблицу, в которой будут вот эти самые агрегированные значения. По скромному моему разумению тут и отдельная таблица не нужна. Поле в таблице CARDNUMBER, содержащее количество записей с null в OPERATIONCARD.DATE_CLOSE, ведущееся на триггерах OPERATIONCARD. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2020, 21:06 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
kdvНапример, в бухгалтериях так всегда делается - типа "закрытие месяца" - считаются данные за месяц, и сохраняются, чтобы их потом не считать каждый раз снова. Ну, тут задача немного не бухгалтерская. Информация динамическая и нужно знать ее в момент запроса пользователем. Посему раз в месяц не катит. Старый плюшевый мишка По скромному моему разумению тут и отдельная таблица не нужна. Поле в таблице CARDNUMBER, содержащее количество записей с null в OPERATIONCARD.DATE_CLOSE, ведущееся на триггерах OPERATIONCARD. Да, да. Так и сделал. Поле туда завет и попытался сперва его отапдейтить. Как писал выше, если по полной апдейтить, то более 20 минут. Завтра поганяю. Тут тоже не все так просто. Одновременно получают дату закрытия до нескольких тысячей записей. Надо посмотреть как триггерок с этим совладает. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2020, 01:40 |
|
Агрегат в подзапросе сильно тормозит FETCH
|
|||
---|---|---|---|
#18+
гуманоидНу, тут задача немного не бухгалтерская. Информация динамическая и нужно знать ее в момент запроса пользователем бухгалтерия тут просто как пример. А насчет динамической информации и "нужно знать" - это сказки. Прямо вот пользователь хочет узнать, какие там количества по 4м миллионам единиц информации? Да он будет тупо смотреть в такой отчет полдня. К примеру, тут вероятно не хранимые агрегаты нужны, а раделение на "закрытые операции" и незакрытые. У нас была система, в которой хранилось дофига данных, и вот заполнено полезной информацией было только 30%. А считать приходилось всё, целиком. Ну и взяли, создали еще одну таблицу, в которую заносили только "заполненную" информацию. А остальная шлабуда была в большой таблице. Поскольку дополнительная таблица была короче, ее объем получился раз в 20 меньше исходной. И отчеты стали просто летать. Это при том, что часть информации дублировалась в старой и новой таблице. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.11.2020, 02:12 |
|
|
start [/forum/topic.php?fid=40&msg=40023020&tid=1560180]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
198ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 311ms |
0 / 0 |