|
|
|
Кривая обработка оптимизатором переменной в where
|
|||
|---|---|---|---|
|
#18+
Добрый день Есть проблемный Delete запрос, выполнение которого занимает пару минут, при том, что записей под удаление он не находит Опытным путем было установлено, что проблема в использование в условии функции с переменной при замене куска Код: sql 1. на Код: sql 1. или добавлении опции Код: sql 1. Запрос отрабатывает мгновенно, так же как и при сборки строки запроса со значениями переменных и выполнении через exec Подскажите, как это обойти без использования констант, оптимизации под фиксированное значение или использования d-sql ? Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2020, 15:16 |
|
||
|
Кривая обработка оптимизатором переменной в where
|
|||
|---|---|---|---|
|
#18+
unno, OPTION (recompile) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2020, 15:30 |
|
||
|
Кривая обработка оптимизатором переменной в where
|
|||
|---|---|---|---|
|
#18+
Плюс статистики должны быть актуальными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2020, 15:47 |
|
||
|
Кривая обработка оптимизатором переменной в where
|
|||
|---|---|---|---|
|
#18+
Владислав Колосов Плюс статистики должны быть актуальными. ну если OPTION ( OPTIMIZE FOR (@i32 = 365) ) работает, то и рекомпайл должен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2020, 16:51 |
|
||
|
Кривая обработка оптимизатором переменной в where
|
|||
|---|---|---|---|
|
#18+
unno, собственно, Код: sql 1. И есть оптимальное решение. Ну, или вместо 365 - другое, наиболее часто используемое значение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2020, 18:30 |
|
||
|
Кривая обработка оптимизатором переменной в where
|
|||
|---|---|---|---|
|
#18+
статистика актуальная OPTION (recompile) помог, спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2020, 22:50 |
|
||
|
Кривая обработка оптимизатором переменной в where
|
|||
|---|---|---|---|
|
#18+
unno, в результате у вас на каждый вызов будет проводится компиляция и кэш планов запросов будет заполняться чучелами планов, занимая память и ресурсы процессора. Для низкой интенсивности запросов к базе - это, возможно, и приемлемо, но это не очень хорошее решение. Вариант с зажатием переменной OPTION ( OPTIMIZE FOR (@i32 = 365) ) - на мой взгляд, лучше. План будет один, раз и навсегда стабильный (при неизменной структуре БД). Начнет внезапно деградировать - уже можно будет осмысливать это. Для вашего, конечно, случая, может всё просто и не требует излишне усложненного понимания ситуации, но вообще то - это антипаттерн. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2020, 09:15 |
|
||
|
|
start [/forum/topic.php?fid=46&msg=39995724&tid=1685691]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 255ms |
| total: | 386ms |
| 0 / 0 |
