|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
Приветствую всех! Есть острая необходимость ускорить выполнение селекта, но пока все попытки (перестраивание запроса, хинты...) закончились неудачей. Прошу помощи в оптимизации, нужно уменьшить время выполнения. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.
Если оставить только subq1, то время выполнения (без подсчёта count(subq2.met_id) N) составляет около 6 секунд (PL/SQL Developer выводит записи через это время). Если добавить TABLE6 t6, то время выполнения увеличивается до 9 секунд. При добавлении subq2 запрос выполняется около 25 минут (отдельно subq2 отрабатывает за 25-30 секунд). План запроса следующий: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2019, 12:13 |
|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
chikaginsk Код: plsql 1.
можем выбиться из индекса из-за ту-чара ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2019, 12:16 |
|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
Забыл написать, что параметры :RAION и (особенно) :AREA принимают довольно много значений (десятки и сотни). ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2019, 12:20 |
|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
andreymx, Поле t7.dt не участвует в индексах. Индексы есть по полям t7.conf_id и t7.met_id (отдельные индексы по каждому из полей). ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2019, 12:24 |
|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
chikaginsk, без понимания того что вообще делает запрос могу предложить только избавиться от exists в subq2, в котором судя по всему и причина, её видно по Код: plaintext 1.
Код: plsql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2019, 14:17 |
|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
feagor, без left, просто join ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2019, 14:19 |
|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2019, 14:58 |
|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
Я же правильно понимаю, что Код: plsql 1. 2.
Равноценно: Код: plsql 1. 2.
А не Код: plsql 1. 2. 3.
? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2019, 15:15 |
|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
DshedooЯ же правильно понимаю, что ? Неправильно. Код: plsql 1. 2.
Равноценно: Код: plsql 1. 2.
Со всеми вытекающими. То что ты видимо хочешь: Код: plsql 1. 2.
SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2019, 15:36 |
|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
SYDshedooЯ же правильно понимаю, что ? Неправильно. Код: plsql 1. 2.
Равноценно: Код: plsql 1. 2.
Со всеми вытекающими. То что ты видимо хочешь: Код: plsql 1. 2.
SY. Эм.... Это же тоже самое, что и я написал о_О ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2019, 15:48 |
|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
chikaginsk, В текущем плане произошел complex view merging для subq2. В виду: chikaginskЕсли добавить TABLE6 t6, то время выполнения увеличивается до 9 секунд. При добавлении subq2 запрос выполняется около 25 минут (отдельно subq2 отрабатывает за 25-30 секунд). Стоит проверить производительность с no_merge для subq2: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.
Если производительность не устроит, то убедиться, что subq2 имеет тот же план отдельно, что и в итоговом запросе. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2019, 21:13 |
|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
chikaginskЕсли оставить только subq1, то время выполнения (без подсчёта count(subq2.met_id) N) составляет около 6 секунд ( PL/SQL Developer выводит записи через это время ).chikaginskЕсли добавить TABLE6 t6, то время выполнения увеличивается до 9 секунд .надо проверять и показывать планы со статистиками по выполнению с фетчем всех строк, а не только первых. chikaginsk Код: plsql 1.
не мешайте оптимизатору рассчитывать кардинальность, замените это на between. Для нормального анализа, надо показывать статистику таблиц и планы выполнения со статистиками! ... |
|||
:
Нравится:
Не нравится:
|
|||
06.04.2019, 00:58 |
|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
andreymx, feagor, Dshedoo, SY, SeaGate, xtender Благодарю всех за ответы! feagor, Проверил все предложенные варианты и остановился на Вашем. Убрал exists и получил значительную прибавку производительности. SeaGate, Хинт этот пробовал, но ускорения не было, хотя план изменился. andreymx, xtender Убрал to_char с поля даты, переделал на between, разницы в производительности не заметил после этого, но хоть оптимизатору мешать не будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2019, 09:22 |
|
Возможно ли ускорить запрос
|
|||
---|---|---|---|
#18+
xtenderнадо проверять и показывать планы со статистиками по выполнению с фетчем всех строк, а не только первых. Для нормального анализа, надо показывать статистику таблиц и планы выполнения со статистиками! Можно ссылку на статью или док по этой теме? Статистиками админ заведует, говорит всё собирается. Но хотелось бы самому разобраться в этом вопросе - в будущем понадобится. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.04.2019, 09:25 |
|
|
start [/forum/topic.php?fid=52&msg=39797162&tid=1882603]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 145ms |
0 / 0 |