Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Проблема с производительностью запроса
|
|||
|---|---|---|---|
|
#18+
Добрый день. Существуют 2 таблицы. Таблица с контактами и таблица с проверками по контактам. Таблица контактов большая, таблица проверок еще больше, ибо на каждого контакта много проверок. Проверки могут быть как ручные, так и автоматические, а так-же проваленные и нет. Была поставлена задача сделать вьюху по проверкам, которая на каждый контакт выводит проверку, по алгоритму. И вот с этой вьюхой проблемы. Алгоритм там примерно следующий: - если существует проваленная проверка, поставленная вручную, то выводить последнюю проваленную проверку, добавленную вручную - во всех прочих случаях выводить просто последнюю проверку. Первая версия (там второе условие было немного другое, выводить последнюю проверку только с момента появления функционала ручных проверок) Код: sql 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. Данная вьюха работала хорошо, когда извне накладывалась фильтрация по контакту, но работала порядка 10-15 минут, когда данной фильтрации не было (режим работы был такой не часто, поэтому со скрипом, но работало так). Впоследствии появилась потребность добавить последнюю проверку по всем контактам, и время формирования вьюхи без фильтрации ушло за 40 минут, что выходило за границы нормальной работы и приводило к вылетам по тайм-ауту страницы. Пересобрал вьюху, выведя алкоритм по сборки в функцию, оставив в самой вьюхе только логику сборки. Получилось вот так. Код: sql 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. С одной стороны помогло. Запрос стал формироваться полторы минуты. Но с другой стороны он формируется полторы минуты независимо от того, есть ли внешняя фильтрация или нет. Перевести на хранимку с параметром не могу, система запрашивает данные именно со вьюхи Есть идеи, как и что можно изменить, чтоб выйти на адекватное рабочее время работы вьюхи? Подозреваю, что outer apply по двум большим таблицам сильно грузит, но не понимаю, как можно сделать без него. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2019, 14:55 |
|
||
|
Проблема с производительностью запроса
|
|||
|---|---|---|---|
|
#18+
1. Завязать с группировками. 2. Освоить exists(). И пребудет с тобой щастье.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2019, 15:03 |
|
||
|
Проблема с производительностью запроса
|
|||
|---|---|---|---|
|
#18+
Да и ваще - хреново пишете, товарищ майор. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2019, 15:18 |
|
||
|
Проблема с производительностью запроса
|
|||
|---|---|---|---|
|
#18+
Добавить в таблицу вычисляемый столбец Код: sql 1. Создать индекс Код: sql 1. Переписать функцию Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2019, 18:45 |
|
||
|
|

start [/forum/topic.php?fid=46&gotonew=1&tid=1687985]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
91ms |
get topic data: |
12ms |
get first new msg: |
7ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
| others: | 272ms |
| total: | 480ms |

| 0 / 0 |
