Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
asa 9.0.2. вот сижу ускоряю запрос +
|
|||
|---|---|---|---|
|
#18+
Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2006, 05:38 |
|
||
|
asa 9.0.2. вот сижу ускоряю запрос +
|
|||
|---|---|---|---|
|
#18+
По вопросу 2 ничего менять не нужно. По вопросу 1 - нужно начинать смотреть само представление. План запроса не самый лучший - куча UNION ALL (судя по всему используются одни и те же вложенные представления), сверху группировка и сортировка по неплохому обьему данных. Тут или в представлении избавляться от вложенных представлений для этого запроса, или изменить соединения (к примеру увести на subquery или LATERAL), или вместо представления сделать ХП и разгрузить повторные чтения через временные нетранзакционные таблицы. В любом случае не видя запросов представлений, не скажешь, чего можно улучшить. P.S. 40 минут выполнения запроса на такое маленькое кол-во записей конечно многовато будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2006, 07:25 |
|
||
|
asa 9.0.2. вот сижу ускоряю запрос +
|
|||
|---|---|---|---|
|
#18+
сенкс а размер страницы 8192 байта. это не мало? (не много?) по статье. не понятен текст: ------ Разветвленность составных индексов Когда используются составные индексы, состоящие из множества полей, они имеют такую характеристику, как разветвленность. Чем больше значений имеет поле индекса, тем больше веток имеет индекса, а значит он занимает больше страниц в базе данных, требует большего времени на чтение и меньше кэшируется. ------- че такое разветвленность не понятно, и не понятно, к чему разветвленность к размеру индекса. ведь чем больше значений имеет индекс, "тем больше он занимает страниц в базе данных, требует большего времени на чтение и меньше кэшируется". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2006, 02:08 |
|
||
|
asa 9.0.2. вот сижу ускоряю запрос +
|
|||
|---|---|---|---|
|
#18+
а почему такая большая разница в оценках в плане со статистикой и плане без статистики? без статистики ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2006, 05:30 |
|
||
|
asa 9.0.2. вот сижу ускоряю запрос +
|
|||
|---|---|---|---|
|
#18+
со статистикой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2006, 05:31 |
|
||
|
asa 9.0.2. вот сижу ускоряю запрос +
|
|||
|---|---|---|---|
|
#18+
ASCRUS P.S. 40 минут выполнения запроса на такое маленькое кол-во записей конечно многовато будет. Запрос выполняется секунд пять, в мессаджах в isql говорит что 0.2 сек., а в плане - 40 минут. Тоже странно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2006, 22:54 |
|
||
|
asa 9.0.2. вот сижу ускоряю запрос +
|
|||
|---|---|---|---|
|
#18+
к вопросу о скорости выполнения "not exist подзапроса" и "left outer join с group by" ---- вот одно из узких мест тормозящего запроса, план которого приведен выше. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. /* попытка комментария есть сущности idu, которые могут обьединяться в группы kgu. есть сущности idc, которые могут обьединяться в группы kpc. для каждой сущности существует группа с таким же номером и содержащаю из сущности. группы могут входить в группы. сущность которая содержит - предок для содержимой, которая содержится потомок от содержащей. для пары (idu_или_kgu , idc_или_kpc) задается атрибут acc со значением val 0 или 1. атрибут наследуется от предков к потомкам. таблица acc содержит четверки (kgu, kpc, acc, val) обзор acc1 содержит теже четверки (kgu, kpc, acc, val ) дополненные до всех окончательных потомков (idu, idc). Значение val характеристики acc наследуется всеми окончательными потомками (idu, idc). надо выбрать все четверки (idu, idc, acc, 1) у которых нет любых предков (kgu, kpc, acc, 0) */ скорость запроса 1 ( not exist подзапрос) ( кроме того, что в нем оказалась ошибка) на некоторых данных была удовлетворительная, на некоторых (при acc = 1) - нет и достигала 40 секунд при полной загрузка процессора. а время выполнения запроса 3 через серию таких обзоров Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. /* то есть каждая тройка (idu, idc, acc, 1) расширена всеми ее предками (kgu, kpc, acc, 0), со значениями атрибута = 0, если они есть. и в следующем запросе с group by выбраны все тройки (idu, idc, acc) у которых нет указанных предков. */ Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. на тех же данных, что и в запросе 1, оказывалось меньше секунды. Загрузка процессора почти не менялась. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 05:09 |
|
||
|
asa 9.0.2. вот сижу ускоряю запрос +
|
|||
|---|---|---|---|
|
#18+
что интересно предсказания оптимизатора в запросе 1 даже лучше чем в запросе 3. Код: plaintext 1. 2. 3. 4. Код: plaintext 1. 2. 3. и планы очень похожие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2006, 05:18 |
|
||
|
|

start [/forum/topic.php?fid=55&fpage=87&tid=2013022]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
31ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
2ms |
| others: | 245ms |
| total: | 371ms |

| 0 / 0 |
