|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
vyegorov, У вас связка shipment+shipment_pc возвращает всего 938 записей: Код: sql 1. 2.
Подзапрос md полностью сканирует shipments ещё раз и он занимает более 2 минут. Я бы внёс условия с датами по shipment внутрь подзапроса md или зациклил LATERAL-ом по датам. Надо пробовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2018, 14:38 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
vyegorov, Спасибо за наводку. Еще меня сильно смущает самая дорогая операция Код: plaintext 1. 2. 3.
Как думаете ? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2018, 16:14 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
rinace, Кстати, помню здесь спрашивали о LASERMARK. Значения данного поля неуникальны Код: plaintext 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. 28. 29. 30. 31.
... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2018, 16:17 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
Коллеги, похоже история близится к финалу. Итак на тестовой базе 10.5 имеем улучшенный запрос (без коррелированного подзапроса) Код: plaintext 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.
Код: plaintext 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. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38.
Наиболее дорогая операция выделена. Для улучшения запроса и исключение наиболее ресурсной операции , было предложено использовать Код: plaintext 1. 2. 3. 4. 5.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
C планом выполнения : Код: plaintext 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.
Т.е. запрос был улучшен в 3 раза. Рефрешиться представление примерно 18 секунд. И учитывая специфику приложения не так часто будет требоваться. Таким образом история начавшаяся с 2-х часов выполнения запроса, завершилась несколькими секундами. Что тут еще можно протьюнит, уже фантазии не хватает. Если кто подскажет, спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2018, 15:41 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
rinaceКоллеги, Execution time: 7712.509 ms Т.е. запрос был улучшен в 3 раза. Рефрешиться представление примерно 18 секунд. И учитывая специфику приложения не так часто будет требоваться. 8 + 18 = 26 > 24455.391 ms т.е суммарно проиграно 4 сек. но зато матвьюху можно индексировать, в отличие от цте. но лучше триггерно поддерживаемое самопальное (опция -- индексы) "матвью" -- оно вам целостность обеспечит ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2018, 16:19 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
qwwqrinaceКоллеги, Execution time: 7712.509 ms Т.е. запрос был улучшен в 3 раза. Рефрешиться представление примерно 18 секунд. И учитывая специфику приложения не так часто будет требоваться. 8 + 18 = 26 > 24455.391 ms т.е суммарно проиграно 4 сек 2 сек. и актуальность в моменте. но зато матвьюху можно индексировать, в отличие от цте. но лучше триггерно поддерживаемое самопальное (опция -- индексы) "матвью" -- оно вам целостность обеспечит -- поправил ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2018, 16:22 |
|
Оптимизация запроса
|
|||
---|---|---|---|
#18+
rinace, Попробуйте такой вариант: Код: 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. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44.
Нужны будут индексы на shipment.SHIPMENT_DATE wafer_data_small.SHIPMENT_ID Хотя логика не много другая ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2018, 22:15 |
|
|
start [/forum/topic.php?fid=53&msg=39717662&tid=1995441]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
52ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 154ms |
0 / 0 |