как оптимизировать запрос 1с 8 #739339

Есть вот такой запрос. И он здорово тормозит отчет. Как его оптимизировать? Спасибо.     ВЫБОР         КОГДА ЗаказыКлиентовОбороты.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг

Есть вот такой запрос. И он здорово тормозит отчет. Как его оптимизировать? Спасибо.     ВЫБОР         КОГДА ЗаказыКлиентовОбороты.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг

а что такое ВТ?

сомнительного свойства запрос

И ещё замер производительности выдает что тормозит вот эта строчка. Можно что-то подкрутить в настройках интерфейса СКД чтобы было быстрее?

1. отбор в условия виртуальной таблицы 2. виртуальную таблицу во временную пересмотреть состав накладываемых условий

если он вызывается 100500 раз в цикле/, то понятно почему отчет тормозит

временная таблица

.Обороты(&МоментВремениРегистратора, &МоментВремениРегистратора, ...

ВТ - это временная таблица. Или я в терминах ничего не понимаю. Но вообще-то это МенеджерВременныхТаблиц.

+ и из ГДЕ после этого условие можно убрать

спасибо, сейчас попробую!!!

Первое понятно, прошу аргументировать второе.

Если выбираются обороты по одному документу, то виртуальная таблица не нужна.

Можно и не обращаться к виртуальной таблице Обороты. Можно просто отобрать по регистратору непосредственно из РегистрНакопления.ЗаказыКлиентов, если что свернуть по номенклатуре и потом соединить.

Насколько я знаю всегда быстрее отчет работает если обращаться к виртуальным таблицам, а не к самому регистру.

или это не так ?

какую задачу решаешь запросом? может быть анализировать приход/расход и не задействовать регистратор?

Это было бы так если бы было обращение к остаткам, а обороты будет строиться из РегистрНакопления.ЗаказыКлиентов применяя группировку по , Регистратор, и выбранные измерения в ВЫБРАТЬ. В вашем случае вы вытаскиваете все движения по регистру накопления за все время, они группируются по правилу выше, потом ( если это MS SQL ) режется по ГДЕ и потом делается ЛЕВОЕ СОЕДИНЕНИЕ, если файловая то левое соединение будет первым потом урезка по ГДЕ ( вроде так )

тут таблица оборотов и не нужна

попробуй проиндексировать ВТ по Номенклатура

задача следующая: "покажи мне какая номенклатура была оплачена!" мне приходится собирать все документы оплаты, а потом по каждому документу оплаты проверять документ-основание (реализация или заказ), и сумму оплаты разносить по всем позициям номенклатуры этого документа.

Сделала так: РегистрНакопления.ЗаказыКлиентов.Обороты(&МоментВремени, &МоментВремени, , ) не прокатило, по моменту времени он ничего не находит.

спасибо за объяснение, сейчас попробую

а ЗаказыКлиентов двигают документы оплаты?

в регистр ЗаказыКлиентов пишут документы оплаты?

Добавь в параметру виртуальной таблицы отбор по номенклатуре из ВТ ИЗ     РегистрНакопления.ЗаказыКлиентов.Обороты( , Номенклатура В (ВЫБРАТЬ ВТ.Ссылка ИЗ ВТ КАК ВТ) , Регистратор, ) КАК ЗаказыКлиентовОборот

нет, сначала я из другого регистра достаю документы оплаты и документ-основание, а потом по документ-основание делаю запрос, который вы и видите выше. я пыталась реализовать это в одном запросе, но, честно говоря, такая ерунда получилась...

у вас в одном документе реализации только одна номенклатура? если нет, то вы уверены что задача методически верна сама по себе?

тут надо понять что именно содержит ВТ а то, теоритически, такое условие может наоборот замедлить запроса

Нет, не одна. Но отчет выдает правильный результат. Методически это решение кажется мне наиболее правильным, но я, конечно, могу ошибаться. Насчет ВТ. Начальник пожелал чтобы номенклатура была разбита на 6 разделов в отчете - инвентарь, оборудование итп. Проще всего было реализовать это, просто разместив её по 6 нужным папкам. Но "менеджеры привыкли к текущей схеме, менять нельзя"! Пришлось пойти обходным путем. Вот запрос ВТ: ВЫБРАТЬ

условия лучше указывать в условиях виртуальной таблицы   ВЫБОР         КОГДА ЗаказыКлиентовОбороты.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг это действие относится не к выботке данных а к представлению данных. соответственно обрабатывайте не на субд.

спасибо!

это не факт если важна скорость то нужно замеры делать, где будет быстрее на сервере или клиенте

вы же понимаете, что такой хардкодинг потенциально неустойчивый?

К стати ЗаказыКлиентовОбороты.СуммаОборот * -1 достаточно заменить на -ЗаказыКлиентовОбороты.СуммаОборот перемножения не будет

Я бы в ВТ еще бы оплаченные заказы клиента добавил: ИЗ     РегистрНакопления.ЗаказыКлиентов.Обороты(             ,             ,

тогда совет в точно не нужен

Если нужно получить движения документа по регистру "ЗаказыКлиентов" с условием по номенклатуре, то быстрее будет обращаться к реальной таблице и ее данные соединять с номенклатурой из ВТ.

Вам нужно вместо ВЫБОР ... КОГДА Номенклатура.Ссылка В ИЕРАРХИИ лучше сделать отборы с условием В ИЕРАРХИИ И потом эти оборы ОБЪЕДИНИТЬ ВСЕ я думаю это будет быстрее значительно.

Пока писал коммент по регистру не успел увидеть запрос выборки номенклатуры. Вот где дикая дичь! Построитель плана запроса "сойдет с ума" от такого точно. Все предопределенные папки выносите в массивы и передавайте как параметр, а уже потом только используйте "В ИЕРАРХИИ(&НаборПапок1)", "В ИЕРАРХИИ(&НаборПапок2)"...

Спасибо! Знаю, что топорно, а как грамотно сделать не знала. Попробую по-вашему.

+ к , разнести куски по подзапросам, меняя условия вхождения в иерархию.

Нахуа так делать? В начале вытащить на клиента, потом отправить на сервер... Всё в одном запросе через виртуальную таблицу, просто запрос написать нормально.

В запросах у неё всё плохо, но глаза шикарные :)

С чего взял, что что-то передается между кл и серв? Откуда вообще мы знаем, что это все в УП происходит? А время на формирование ВТ, индексирование ее полей учитываешь? И конструкция "В ИЕРАРХИИ(Выбрать ПапкаСсылка ИЗ..)" будет медленнее работать чем "В ИЕРАРХИИ(&ВыбПапки)" — х.з. из-за чего, но экспериментально быстрее получается.

бред редкостный. но 25 лет я писал также. у Вас тяжелай форма болезни одинесника: путать получение данных с представлением данных. методически Ваше решение плохое, тк будет требовать постоянной доработки отчета, для добавления удаления групп . замените ваш список  на  бд РС либо справочник. Альтернативное видение иерархий, группировок, фильтров   - это нормальная часть бизнес процессов. но периодически требует секвестирования. в вашем Запросе нужно отказаться от обработки представления в субд. Считать справочник и построить иерархию не клиенте.

чувак, тебя читать так же сложно, как в запрос )

если справочник небольшой то прокатит... , но я бы через доп. свойство сделал. Всеравно новые папки будут создаваться и придется отчет переделывать.

"если справочник небольшой то прокатит" — из-за подобного подхода было загублено не мало ИБ. Когда "специалист" пишет запрос, все вроде бы быстро работает, а через год у людей "таймауты" начинают "валиться".

Все предопределенные папки выносите в массивы и передавайте как параметр, а уже потом только используйте "В ИЕРАРХИИ(&НаборПапок1)", "В ИЕРАРХИИ(&НаборПапок2)"... Подразумевается что номенклатуру в начале ты выберешь несколькими запросами на клиента, затем передашь на сервер в качестве параметров и не важно что толстый клиент там тоже виртуальный сервер. А если сервер не виртуальный то сетевые накладки будут выше чем даже запись виртуальной таблицы, если вообще будет запись вместо курсора...

+100

А что это такое?

на ошибках учаться. "красивей" по крайней мере все в одном запросе...

учатся

Начала пробовать предложенные варианты. переделала в запрос: "ВЫБРАТЬ                           |    ВТ.ГруппыТоваров, Стало выполняться дольше на 10 секунд( или можно как-то из ГДЕ переместить условие на регистратор?

Соединение ВНУТРЕННЕЕ надо, тебе же строго позии номенклатуры из ВТ нужны. Ну и условие можно в условия связи перенести.

Нет, в ВТ я вытаскиваю только Группы номенклатуры. Саму номенклатуру тяну из ЗаказКлиентов

Попробуй сделать так:

Вы уже просто "загнались" с этими "Клиентами" и "Серверами". Ну и зря.

сделай ВТ из заказов клиентов далее Виртуальная таблица быстрей, регистр не нужен... очень криво

Что именно?

1. Цикле отбор номенклатур на клиенте, всё это можно сделать и в 1 запросе. 2. ЛЕВОЕ СОЕДИНЕНИЕ вместо: ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ЗаказыПокупателей КАК ЗаказыПокупателей 3. И почему ты уверен что нужно отбрасывать некоторые позиции заказ если они не входят в эти группы?

избавьтесь от условия ГДЕ, Вам писали уже)

Возьми консоль запросов с инструментом замера времени выполнения запроса и посмотри сколько займет время сделать "одним запросом" и "передать как параметр". Совсем недавно делал нечто подобное и был удивлен, что условие "В" компилятор запроса формирует не так как "В (Выбрать...)". И раза в 3 быстрее сделал (но тут от кол-ва данных будет зависеть ускорение).

Ничего себе... пошла пробовать.

Ты чушь пишешь. Я не предлагал писать В ( ВЫБРАТЬ ... ИЗ ). Если у тебя понимания не хватает я тебе его рихтовать не буду. И я понимаю что "один запрос" это всего лишь один текст, но возможно несколько запросов к базе.

+ к При чем "построитель плана запроса" с третьего или четвертого раза вывел "В (Выбрать...)" на скорость выполнения такую как у "В(&Парам)". Проделывалось на MS SQL 2008 R2.

А ты не кипятись и просто свой вариант покажи. А уж я не поленюсь и прогоню его через замер скорости выполнения и профайлер.

Время запросов в цикле учитывал?

Господа, хорош спорить. У меня еще другой запрос к той же ВТ обращается, но тормозит именно тот который ЗаказКлиента

Номенклатуру-то я конечно переделаю по группам товаров чтоб грамотно-красиво, но проблема не в ней.

нехороший совет будет только хуже

на секунду дольше выполняется

Для каждого ТекСтр Из ГруппыПосуда Цикл     СпрСсылка = Справочники.Номенклатура.НайтиПоНаименованию(ТекСтр); ... это называется запрос в цикле

Когда свой случай решал — да. Найти десяток элементов по индексированному полю это было быстрее даже чем получить эти же элементы одним запросом и поместить их в ВТ. При чем исходил из того, что передавая массив в условие "В", система так же сформирует временную таблицу в tempdb и будет выборкой в ней проверять условия. Оказалось, что ничего подобного.

А как долго у тебя выполняется просто выборка записей РН с условием по &Регистратор? Для нескольких элементов это оправдывается выигрышем в скорости выполнения в дальнейшем (в моем случае было всего 5 таких папок).

ок... может быть    пробовала?

Сравнивай

Код не проверял, не знаю что за конфа если что подправишь огрехи

Да подмени не заметил

покажи весь запрос с документами оплаты УТ11?

да. Я сейчас как раз втыкаю смысл в . У вас там обращение к ВТ, в которой и номенклатура и заказ клиента. У меня в ВТ исключительно номенклатура, запрос к справочнику номенклатуры. Предлагаете создать ВТ с заказами и соединить её с запросом в котором заказы? Зачем? Я соединяю, чтобы отдельно разбивались по группам и не портило основной запрос. А зачем запрос с заказами соединять с ВТ с запросом с заказами как-то не улавливаю.

Я бы в справочник номенклатура лез после того как определил какие именно заказы оплатили...

Думала-думала, решила лучше спросить. Технически как это сделать?) сначала один запрос, потом второй, или как ?)

Ну и вот результат: 1. Твой изначальный вариант — первый запуск 852 мс, далее 440 мс. 2. Изменяю твой вариант и вместо поиска по наименованию "подсовываю" сразу массив с папками — результат колеблется около 330 мс. 3. Не использую ВТ вообще и сразу двумя подзапросами выбираю номенклатуру по переданным группам — результат 250-260 мс. Тут даже особо другого результата и не ожидалось. При большой выборке данных зачастую не дооценивают время формирования всех этих ВТ. Более того, выбирая элементы справочника в ВТ, на них накладывается оптимистическая блокировка и пока моя ВТ что-то там тянет из записей РН, никто не сможет что-то записать в справочник номенклатуры. Выбирая же просто папки и сравнивая с папками я никаким образом не блокирую обычные элементы справочника.

какая конфигурация?

> выбирая элементы справочника в ВТ, на них накладывается оптимистическая блокировка блокировка накладывается если читаешь в транзакции

Разницу между пессимистичной и оптимистичной блокировкой ощущаешь?

УТ 11

и к чему вопрос? там не будет блокировки

Вот спасибо, буду знать!

в фигня, есличо

Консоль запросов врет?

У тебя похоже, особая консоль

Хочешь сказать, что если мы читаем данные из Спр.Номенклатура, помещаем их в ВТ, потом используем эту ВТ дальше, то кто-то в это время может удалить один или несколько элементов Спр.Номенклатура?

Возможно. Но пока с "тормозами" в базе успешно помогала справляться.

Читаем вне транзакции - да. Читаем в транзакции - по разному.

честно скажу, именно удалить не пробовал ты выше пишешь не про удаление, а про изменение нормальная схема, когда удалением занимается администратор, а не так запросто в течение работы пользователей