|
Помогите с запросом
|
|||
---|---|---|---|
#18+
Доброго времени суток. Есть 2 таблицы (для примера): Table1 "легкая" и Table2 "очень тяжелая". Упрощенный запрос для этих таблиц выглядит так: Код: sql 1. 2. 3.
работает достаточно быстро, но когда появляется необходимость сделать проверку по sum_amount, нужно приписывать запрос так: Код: sql 1. 2. 3. 4. 5. 6.
или так: Код: sql 1. 2. 3. 4. 5.
Первый работает долго, второй - быстро. Есть еще варианты с GROUP BY, но они не всегда подходят. Написан не очень умный парсер запросов, и второй запрос распарсить и подставить что-то в него он не может. Такая же сложность для запросов с group by. Может есть варианты для проверки суммы в первом запросе, без select в selectе и без group by? Firebird 3.0 поддерживает over, но что-то я не могу понять как его использовать в данном случае. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 14:13 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
Пардон, второй запрос: select t1.id, tt.sum_amount, iif(tt.sum_amount > 1000, 1, 0) from table1 t1 left join (select t2.id_table1, sum(t2.amount) as sum_amount from table2 t2 group by t2.id_table1) tt on tt.id_table1 = t1.id) where t1..... ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 14:16 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
SHS_SHSкогда появляется необходимость сделать проверку по sum_amount, нужно приписывать запрос так Левый джоин тут не нужен. Order by в deived table - тоже. Наверняка точками прикрыто что-то аналогично бессмысленное. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 14:20 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
С order by ошибся. left остался от оригинального запрос. В where кончено же ерунда написана, как без этого :). Но с просто join работает все равно дольше, чем с select в selectе. Код: sql 1. 2. 3. 4. 5. 6.
Для данного запроса подсчет сумм идет для всей Table2, а уже потом объединение? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 14:32 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovSHS_SHSкогда появляется необходимость сделать проверку по sum_amount, нужно приписывать запрос так Левый джоин тут не нужен. Order by в deived table - тоже. Наверняка точками прикрыто что-то аналогично бессмысленное. А ведь я лет 15 назад говорил господам фичереквестерам, что если что-то может быть использовано через анус, то только так оно и будет использоваться. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 14:35 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
SHS_SHS, в принципе при наличии индекса запрос с LEFT JOIN должен работать достаточно шустро. Приведи полный запрос 2 и его план ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 14:52 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3.
-- 250ms PLAN (T2 INDEX (TABLE2)) PLAN (T1 NATURAL) Код: sql 1. 2. 3. 4. 5. 6.
-- 2s 138ms PLAN JOIN (TT T2 ORDER TABLE2, T1 INDEX (TABLE1)) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 15:18 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
Тут проблема, что самописный парсер не понимает select в selecte, и плохо работает с group by. Есть ли какой-то вариант (как выше сказали "через одно место") сделать что-то быстро в запросе, вроде этого: Код: sql 1. 2. 3.
или смирится со скоростью выполнения второго запроса.... или дописывать парсер. Сейчас парсер понимает все поля (какими бы кривыми не были), все объединения таблиц (подзапросов) через joinы. С group by работает, но с group by можно динамически добавить в запрос поля, а хотелось бы и таблицы (этого нет). ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 15:34 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
SHS_SHS-- 250ms PLAN (T2 INDEX (TABLE2)) PLAN (T1 NATURAL) Здесь ты явно забыл нажать "Fetch All". Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 15:37 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
SHS_SHS, а вот так: Код: sql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 15:40 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
SHS_SHS, чёт планы у тебя какие-то кривоватые мягко говоря или ты индексы по уродливому назвал. Лучше уж explain план. Да ну ладно время не такое уж и большое на самом деле. Сообщи архитектуру и размер страничного кэша. И вообще твоём случае скорее всего вот такого запроса вполне хватит Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 15:43 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
Симонов ДенисSHS_SHS, в принципе при наличии индекса запрос с LEFT JOIN должен работать достаточно шустро. Приведи полный запрос 2 и его план Кстати да, с LEFT JOIN в упрощенной форме запроса работает реально быстрее: Код: sql 1. 2. 3. 4. 5. 6.
--250ms PLAN JOIN (T1 NATURAL, TT T2 ORDER TABLE2) В оригинале запроса для этой связки стоит тоже left join, поменял для другого объединения на left join (хотя там связь без null) и переставил объединение ниже этой - все летает. Похоже оптимизатор наконец-то понял мою ересь мой запрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 15:59 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
Планы криповаты, т.к. за столько лет без ошибок писать так и не научился. -- 250ms PLAN (T2 INDEX (FK_TABLE2_1)) PLAN (T1 NATURAL) -- 2s 138ms PLAN JOIN (TT T2 ORDER FK_TABLE2_1, T1 INDEX (PK_TABLE1_1)) -- 250ms PLAN JOIN (T1 NATURAL, TT T2 ORDER FK_TABLE2_1) FetchAll не нажимал, т.к. там результат в 15-20 строк. Но на всякий проверил, результаты почти такие же. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 16:09 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
SHS_SHS, ИМХО, левый джойн - костыль. Не пробовал мой или последний запрос Дениса? Вроде всё прозрачно. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 16:15 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
В этих запросах group by. Я знаю как написать запрос с ним. Если в двух словах описать почему нельзя, то: Есть "костяк" запроса, который выводит отчет. Но вдруг пользователю нужны еще поля, он в специальной форме выбирает их. Парсер проходит по запросу и подставляет в него поля, и если нужно подключает таблицы. А использование group by "ломает" это. Но все равно спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 16:25 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
KreatorXXI, я бы не сказал что костыль, но у автора явно не тот случай когда именно LEFT JOIN нужен к производной таблице или CTE ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 16:27 |
|
Помогите с запросом
|
|||
---|---|---|---|
#18+
SHS_SHS, понял. У нас тоже есть что-то подобное. Но и есть возможность сделать настраиваемый group by. Конструкция вложенных селектов (не "select from select", а именно вложенных) легче для конструктора запросов. Но, сами видите, провал по производительности очень часто обеспечен. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2019, 16:52 |
|
|
start [/forum/topic.php?fid=40&fpage=21&tid=1560637]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 142ms |
0 / 0 |