Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Запрос: Итого по убыванию + условие.
|
|||
|---|---|---|---|
|
#18+
Добрый день. Вот есть запрос, в котором dbo.Years_qu - таблица с bit - полями (данные за определенный Год: нужен/не нужен Год, или включить/выключить (1 запись-строка)), в другой таблице содержатся итоговые значения закупок каждого конкретного Customer_ID за определенный год (+- 9000 записей). Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Предположим мы хотим не учитывать данные за 14,15 года. Для этого на клиенте в определенной форме указываем: Код: sql 1. 2. Далее нам нужны, например, такие данные: 0-е приходы за 19 и 18 год и Не-0-е за 16,17. Т.е. клиенты, которых мы потерями за прошлый год. А ещё нужна сортировка по убыванию итоговых значений закупок каждого конкретного Customer_ID: Код: sql 1. 2. 3. 4. 5. 6. 7. Последний запрос виснет на сервере на 100-180 секунд и более. Причем условие where T_2019=0 and T_2018=0 выполняется пулей. Как только добавляю T_2017>0 and T_2016>0 включаются тормоза. Пробовал IIF заменить на Case, пробовал умножать Год на Итого и потом суммировать, пробовал <>0, всё равно тормоза ... Понимаю, что данные не кэшируются и нужно что-то изменить, ну чтобы SQL не вис. Как быть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2019, 14:23 |
|
||
|
Запрос: Итого по убыванию + условие.
|
|||
|---|---|---|---|
|
#18+
LightNПоследний запрос виснет на сервере на 100-180 секунд и более. Причем условие where T_2019=0 and T_2018=0 выполняется пулей. Как только добавляю T_2017>0 and T_2016>0 включаются тормоза. Зависает = долго работает но в итоге выполняется или Зависает = долго работает и вы его отменяете ? Если первое, смотрите планы запросов Если второе, попробуйте посмотреть план запроса, если построение плана так же "зависает", то у вас строится/обновляется статистика по полям T_2017, T_2016 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2019, 14:31 |
|
||
|
Запрос: Итого по убыванию + условие.
|
|||
|---|---|---|---|
|
#18+
msLex, В итоге запрос выполняется, но очень-очень медленно. В плане тоже всё ОК. Похоже наступил на какие-то грабли. Возможно расчёт суммы T_Year как-то спотыкается на условии T_2017>0 and T_2016>0 и они мешают друг другу ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2019, 14:50 |
|
||
|
Запрос: Итого по убыванию + условие.
|
|||
|---|---|---|---|
|
#18+
а не LEFT JOIN нужен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2019, 13:16 |
|
||
|
Запрос: Итого по убыванию + условие.
|
|||
|---|---|---|---|
|
#18+
LightNПробовал IIF заменить на Case, пробовал умножать Год на Итого и потом суммировать, пробовал <>0, всё равно тормоза ... Понимаю, что данные не кэшируются и нужно что-то изменить, ну чтобы SQL не вис. Как быть? Вы меня пугаете. Используете фильтр по вычисляемому полю и ишо жалуетесь на жисть. Самом собой - сканирование таблицы и быстро не будет никогда. ЗЫ. Про "архитектуру" я лучше промолчу. Но "быстро" = полная перестройка вашего сарая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2019, 10:03 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39769227&tid=1688324]: |
0ms |
get settings: |
8ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
136ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 244ms |
| total: | 487ms |

| 0 / 0 |
