Оптимизация запроса к виртуальной таблице остатков
есть запрос по остаткам.
В параметры виртуальной таблицы передается список товаров. Знаю, что при небольшом списке происходит поиск по индексу, если список большой, запрос преобразуется в товар1 или товар2 и т.д. (т.е. происходит сканирование)
Как оптимизировать данный запрос?
ВЫБРАТЬ
| ОстаткиОстатки.Товар КАК Товар,
| ОстаткиОстатки.Склад,
| ОстаткиОстатки.Сектор,
| ОстаткиОстатки.Ячейка,
| ОстаткиОстатки.МеркурийПартия,
| ОстаткиОстатки.Сектор.Сортировка КАК Приоритет,
| ОстаткиОстатки.ОстатокОстаток - ОстаткиОстатки.РезервОстаток КАК Остаток,
| ОстаткиОстатки.БазСуммаОстаток КАК База,
| ОстаткиОстатки.ВалСуммаОстаток КАК Вала,
| ОстаткиОстатки.ОстатокОстаток КАК Всего
|ИЗ
| РегистрНакопления.Остатки.Остатки(, Товар В (&Товары)) КАК ОстаткиОстатки
|ГДЕ
| ОстаткиОстатки.ОстатокОстаток - ОстаткиОстатки.РезервОстаток > 0 ПоказатьВ параметры виртуальной таблицы передается список товаров. Знаю, что при небольшом списке происходит поиск по индексу, если список большой, запрос преобразуется в товар1 или товар2 и т.д. (т.е. происходит сканирование)
Как оптимизировать данный запрос?
По теме из базы знаний
- Виртуальная таблица «Остатки» регистра накопления и избыточные блокировки
- Проблема быстродействия при использовании позиции документа вместо Даты в виртуальных таблицах
- Оптимизация запросов 1С:Предприятие – от теории к практике
- Оптимизация запроса к виртуальной таблице регистра накопления
- Регистры бухгалтерии. Виртуальная таблица оборотов
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Согласен со сканированием таблицы. Здесь еще зависит от индексирования реквизита "Товар" в рег.накопления или если нет индексирования по этому реквизиту, то надо посмотреть на какой позиции в структуре рег.накопления находится реквизит
(пример:
1. Склад (по умолчанию индексируется)
2. Подразделение
3. Товар
1. Количество
2. Сумма).
Если на первом месте идут склады или еще что-то, а потом только товар, то желательно добавить отборы по складу или еще по какому-нибудь реквизиту.
(пример:
1. Склад (по умолчанию индексируется)
2. Подразделение
3. Товар
1. Количество
2. Сумма).
Если на первом месте идут склады или еще что-то, а потом только товар, то желательно добавить отборы по складу или еще по какому-нибудь реквизиту.
(4)
В регистре порядок следующий:
Товар, Склад, Сектор, Ячейка.
Вообще вроде по умолчанию создается кластерный индекс со всеми измерениями в порядке данном.
(1) Согласен со сканированием таблицы. Здесь еще зависит от индексирования реквизита "Товар" в рег.накопления или если нет индексирования по этому реквизиту, то надо посмотреть на какой позиции в структуре рег.накопления находится реквизит
В регистре порядок следующий:
Товар, Склад, Сектор, Ячейка.
Вообще вроде по умолчанию создается кластерный индекс со всеми измерениями в порядке данном.
(5)
Выполняется запрос, если выставить условия только по товару от 0.1 до 1 секунды в зависимости от количества товара в условии. Если в условии небольшое количество, то идет поиск по индексу. Вообще в итоговом запросе кроме товара, есть ограничения по складу и сектору. Вот в данном случае запрос может до 8 секунд выполняться: (Товар В (&Товары), Склад В (&Склады), Сектор В &(Сектора)).
К примеру при проводке 19 накладных выполняется запрос - 60 секунд со всеми условиями.
Что пробовал сам:
1.В условие подавать декартово произведение (выполняется для 19 накладных около 25 секунд):
(Товар, Склад, Сектор) В (Выбрать ВТ_Товары.Товар, ВТ_Склады_Сектора.Склад, ВТ_Склады_Сектора.Сектор ИЗ ВТ_Товары, ВТ_Склады_Сектора)
2. Быстрее всего работает запрос с условием только по товару, помещение во временную таблицу и потом отбор по складу и сектору. (для 19 накладных 8 секунд). Но на мой взгляд я лишние строки из регистра блокирую.
Выполняется запрос, если выставить условия только по товару от 0.1 до 1 секунды в зависимости от количества товара в условии. Если в условии небольшое количество, то идет поиск по индексу. Вообще в итоговом запросе кроме товара, есть ограничения по складу и сектору. Вот в данном случае запрос может до 8 секунд выполняться: (Товар В (&Товары), Склад В (&Склады), Сектор В &(Сектора)).
К примеру при проводке 19 накладных выполняется запрос - 60 секунд со всеми условиями.
Что пробовал сам:
1.В условие подавать декартово произведение (выполняется для 19 накладных около 25 секунд):
(Товар, Склад, Сектор) В (Выбрать ВТ_Товары.Товар, ВТ_Склады_Сектора.Склад, ВТ_Склады_Сектора.Сектор ИЗ ВТ_Товары, ВТ_Склады_Сектора)
2. Быстрее всего работает запрос с условием только по товару, помещение во временную таблицу и потом отбор по складу и сектору. (для 19 накладных 8 секунд). Но на мой взгляд я лишние строки из регистра блокирую.
(10)Могу предложить попробовать вынести за этот запрос строку:
А в запросе выбрать только Сектор.
Сортировку получать отдельным запросом, после выполнения этого.
Возможно будет лучше.
ОстаткиОстатки.Сектор.Сортировка КАК Приоритет,
А в запросе выбрать только Сектор.
Сортировку получать отдельным запросом, после выполнения этого.
Возможно будет лучше.
(14)Попробовал, тоже нуль эффекта, а если я все таки остановлюсь на временных таблицах и отборе уже в ней по складу и сектору, как самом быстром варианте. Блокируются в транзакции у меня считанные строки с регистра будут(то есть все товары без отбора по складу и сектору) ?или уже отобранные во временной?
(15)
Попробуйте рекомендации из этой статьи, может чем то помогут... это для параллельности работы. Запрос не ускорится.
А если запрос делать по товару и складу, результат поместить в ВТ, а потом уже в ВТ по сектору?
Сектор это что за аналитика? Дополнительная аналитика внутри склада?
Попробуйте рекомендации из этой статьи, может чем то помогут... это для параллельности работы. Запрос не ускорится.
А если запрос делать по товару и складу, результат поместить в ВТ, а потом уже в ВТ по сектору?
Сектор это что за аналитика? Дополнительная аналитика внутри склада?
(17)В общем потестил, быстрее всего работает поиск по товару и складу. Но! К примеру у меня 50 товаров и 20 складов. Работает ваще быстро около 0.4 секунды. Проблема другая -блокируется вся таблица и все( Почему блокируется вся таблица понять не могу. Вроде в профайлере глянул идет clustered index seek.
Можно попробовать использовать реальные таблицы.
Если посмотрите план по запросу из виртуальных таблиц, то он будет иметь вид:
Sel ect * from (select *, MAX (период) fr om реальная_таблица).
По регистрам накопления не пробовал, а свой срез последних по Регистру сведений, как правило, всегда давал прибавку к быстродействию. Сначала получаете максимальный период, а затем по этому периоду опять соединяетесь с регистром.
Для понимания логики:
Затем получаете сами остатки:
Если посмотрите план по запросу из виртуальных таблиц, то он будет иметь вид:
Sel ect * from (select *, MAX (период) fr om реальная_таблица).
По регистрам накопления не пробовал, а свой срез последних по Регистру сведений, как правило, всегда давал прибавку к быстродействию. Сначала получаете максимальный период, а затем по этому периоду опять соединяетесь с регистром.
Для понимания логики:
Выбрать
Товар.Товар,
Максимум(Остаток.Период) КАК ПоследнийПероиодОстатков
Поместить ВТ_ПоследниеДвиженияПоТовару.
ИЗ Товар Как Товар
левое соединение РегистрНакопления.Остатки Как Остаток
ПО Товар.Товар = Остаток.Товар
Затем получаете сами остатки:
Выбрать ВТ_ПоследниеДвиженияПоТовару.Товар,
Остатки.ОстатокОстаток - Остатки.РезервОстаток КАК Остаток
ИЗ ВТ_ПоследниеДвиженияПоТовару КАК ВТ_ПоследниеДвиженияПоТовару
Левое соединение РегистрНакопления.Остатки Как Остатки
ПО ВТ_ПоследниеДвиженияПоТовару.Товар = Остатки.Товар
И ВТ_ПоследниеДвиженияПоТовару.ПоследнийПероиодОстатков= Остатки.Период
ГДЕ
Остатки.ОстатокОстаток - Остатки.РезервОстаток >0
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот