для ут 10.3 помогите оптимизировать запрос -

```1c
    ВЫБРАТЬ РАЗЛИЧНЫЕ
    ВЫРАЗИТЬ(ЗаказыПокупателейОстатки.ЗаказПокупателя КАК Документ.ЗаказПокупателя) КАК ЗаказПокупателя
    ИЗ
    РегистрНакопления.ЗаказыПокупателей.Остатки(, ЗаказПокупателя В (&МассивДокументов)) КАК ЗаказыПокупателейОстатки
    ГДЕ
    ЗаказыПокупателейОстатки.КоличествоОстаток <> 0
```

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

Проверьте, индексируется ли у Вас измерение "ЗаказПокупателя", либо стоит ли оно первым среди измерений регистра? Если так, не представляю, чем еще можно помочь. Разве что убрать ключевое слово "РАЗЛИЧНЫЕ", оно здесь бессмыслено. Ну и проверить актуальность итогов в базе.

Может стоит рассмотреть модификацию запроса списка, путем добавления левого соединения основной таблицы с таблице остатков?
---
А что не так? Вполне корректный запрос, если Вы действительно пытаетесь получить только те заказы, по которым есть остаток. Из исходной таблицы Вы остаток не получите, только если станете рассчитывать его сами. Но этот способ очевидно более ресурсозатратный, т.к. при поддержке итогов ИБ в актуальном состоянии, данные для представленной виртуальной таблицы уже есть в базе, хранятся в отдельной таблице и их не нужно рассчитывать.
---
он выполняется для списка при событие При получение данных, из-за этого список медленно листается, в замере производительности 90 процентов тратиться на этот запрос.
---
Ну так это важное условие, зря Вы его опустили в исходном сообщении. :)

Проверьте, индексируется ли у Вас измерение "ЗаказПокупателя", либо стоит ли оно первым среди измерений регистра? Если так, не представляю, чем еще можно помочь. Разве что убрать ключевое слово "РАЗЛИЧНЫЕ", оно здесь бессмыслено. Ну и проверить актуальность итогов в базе.

Может стоит рассмотреть модификацию запроса списка, путем добавления левого соединения основной таблицы с таблице остатков?
---
там не управляемая форма, и список формируется не запросом.
Что я не указал в исходном сообщение? я вас не понимаю

Измерение не индексировалось и стояло 2 в списке(порядок в списке на что то влияет? )
Сейчас поставил индексацию и первым, по результату отпишусь
---
Измерения регистра сами индексируются.

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

У меня ощущение, что запрос не виноват
---
чше время выполнения 1 запроса и количество запросов, которое было сделано в измеряемый промежуток времени.

У меня ощущение, что запрос не виноват

вот замер производительности по нем
---
Попрогбуй так

```1c
    ВЫБРАТЬ
    Заказ.Ссылка КАК ЗаказПокупателя
    ПОМЕСТИТЬ ВТ_ЗаказыПокупателя
    ИЗ
    Документ.ЗаказПокупателя КАК Заказ
    ГДЕ
    Заказ.Ссылка В(&МассивДокументов)

    ИНДЕКСИРОВАТЬ ПО
    ЗаказПокупателя

    ;
    ВЫБРАТЬ
    ЗаказыПокупателейОстатки.ЗаказПокупателя КАК ЗаказПокупателя
    ИЗ
    РегистрНакопления.ЗаказыПокупателей.Остатки(, ЗаказПокупателя В (ВЫБРАТЬ ВТ_ЗаказыПокупателя.ЗаказПокупателя ИЗ ВТ_ЗаказыПокупателя КАК ВТ_ЗаказыПокупателя)) КАК ЗаказыПокупателейОстатки
    ГДЕ
    ЗаказыПокупателейОстатки.КоличествоОстаток <> 0
```
---
Индексируются, но по умолчанию в том порядке, как они заданы в конфигураторе. Коли заказ оказался на втором месте, индекс может не использоваться, т.к. пропущено условие по первому измерению. Здесь либо изменить порядок, либо проиндексировать заказ. Оба действия делать не обязательно.
---
вечная проблема. С запросом ничего не сделаешь. Оптимизировать это все можно пытаться какими-то другими путями, но они все будут неидеальны. Например в заказе сделать реквизит - конечный остаток по заказу и тщательно заполнять его при всех движениях. И по нему делать отбор. А допустим по ночам проверять его запросом остатков по регистру один раз в сутки.
Или объяснить пользователям, что увы.
База файловая? Сиквел нужен с хорошим сервером для таких списков.
---
база sql, два отдельных сервера 1с и sql, причем сервер 1с загружен очень слабо. на сервере sql также ресурсов памяти и процессора достаточно
---
еще вариант сделать сразу список заказов с ненулевым остатком. При открытии формы такой запрос по всем заказам и в список только заказы с остатками. Тогда он открываться будет подольше, но список будет работать как обычный список, быстро.
При листании списка такие запросы это дохлый номер.
---
некоторые с утра зашли в базу и до вечера не выходят, получиться что весь день в списке будут не актуальные данные =(

а если сделать я вот думаю константу глобальную. и регламентным заданием раз в пару минут ее обновлять, также быстрее будет?
---
(16)вообщем стало гораздо быстрее работать, после того как в регистре поставил для измерения Заказ индексацию, и первым в списке его
---
ЗаказПокупателя В (&МассивДокументов)

Это делать не рекомендуется. особенно если в массиве много документов.
Лучше получить их в временной таблице, проиндексировать и внутренним соединением фильтровать или

ЗаказПокупателя В (ВЫБРАТЬ ВТ.Заказ ИЗ ВТМассивДокументов КАК ВТ)
---
зачем поднимать данные во временную таблицу? Что за бред?
---
Для виртуальной таблицы необходимо все условия заносить в условия виртуальной таблицы а не в условие ГДЕ
т.е. там же где находится условие ЗаказПокупателя В (&МассивДокументов)
---
Извините, но это глупость. Там возможны только условия по измерениям. Вы не сможете добавить условия по полям остатка в параметры виртуальной таблицы.
---
кстати да, забыла, подзабыла запросы
---
Лучше оптимизировать получение &МассивДокументов.
---
как ? запрос выполняется для списка документов, массив получаю 1 раз-

```1c
    МассивДокументов = Новый Массив;
    Для каждого ОформлениеСтроки Из ОформленияСтрок Цикл
    МассивДокументов.Добавить(ОформлениеСтроки.ДанныеСтроки.Ссылка);
    КонецЦикла;
```
---
Вопрос оптимизации возник из-за большого размера МассивДокументов?
Запрос к регистру накопления у Вас корректный.
---
это выполняеться для списка, список медленно листается ,в массиве всего около 40 документов.
---
А запрос ДС покажи на всякий)) и скажи в замере сколько раз этот запрос выполнился?
---
ДС покажи на всякий)) и скажи в заме какой ДС?
вот он в замере производительности
---
ДС - динамический список. (конечно же неуместный вопрос для неуправляемых форм. Каюсь)

1755 раз. А время выполнения 1 запроса?
---
Вообщем всем спасибо, запрос остался тот же, индексация измерения в регистре Заказ покупателя, очень сильно помогла, список стал листатся очень быстро! Всем спасибо, не знал что индексация так влияет.
---
Как вариант:

```1c
    ВЫБРАТЬ
    ВЫРАЗИТЬ(ЗаказыПокупателейОстатки.ЗаказПокупателя КАК Документ.ЗаказПокупателя) КАК ЗаказПокупателя
    ИЗ
    РегистрНакопления.ЗаказыПокупателей.Остатки КАК ЗаказыПокупателейОстатки
    ВНУТРЕННЕЕ СОЕДИНЕНИЕ
    Документ.ЗаказПокупателя КАК ЗаказыПокупателейДокументы ПО ЗаказыПокупателейДокументы .Ссылка В (&МассивДокументов)
    И ЗаказыПокупателейОстатки.ЗаказПокупателя = ЗаказыПокупателейДокументы.Ссылка
    ГДЕ
    НЕ ЗаказыПокупателейОстатки.КоличествоОстаток = 0
    СГРУППИРОВАТЬ ПО ЗаказПокупателя
```
---
В этом случае сначала будет получена виртуальная таблица остатков по всем заказам, а потом уже будет отфильтрована по нужным. Вряд ли это может быть оптимальнее, чем фильтровать таблицу итогов до получения остатков. Ну и группировка здесь совершенно лишняя.
---
Нет, там будет произведено связывание таблиц с index scan в худшем случае, что чаше быстрей создания отдельной таблицы.

По поводу индексирования: индексирование тратит слишком много времени и обычно неэффективно в случае однократного использования таблицы далее (там создаётся кластерный индекс, что, по сути, равно созданию второй таблицы)
---
По поводу индексирования
Речь об индексировании измерения регистра?
---
индексирование вот это:

```1c
    ВЫБРАТЬ
    Заказ.Ссылка КАК ЗаказПокупателя
    ПОМЕСТИТЬ ВТ_ЗаказыПокупателя
    <skipped>
    ИНДЕКСИРОВАТЬ ПО
    ЗаказПокупателя
```

Что физически происходит - создаётся новая таблица, потом она целиком сканируется для создания индекса и создаётся кластерный индекс, который содержит все колонки таблицы, т.е. создаётся ещё одна такая же таблица
---
А, ну это не мое предложение. :) И согласен с Вами.
---
связывание таблиц с index scan
Спасибо, возьму на заметку.
---
ГДЕ
НЕ ЗаказыПокупателейОстатки.КоличествоОстаток = 0

лишнее
---
Нет, если есть и другие ресурсы регистра
---
Да, согласен. Не учел, что ресурсов несколько и они могут списываться неровно. Сумма по идее должна списываться вместе с количеством.
---
Что за бред - думаешь только 1 ресурс может быть в таблице? По количеству 0, а по сумме или еще какому-то ресурсу не 0
(35) Потому что читать ИТС нужно и не называть бредом. А почитать нужно "практическое пособие разработчика" хотя бы. Там написаны рекомендации - "как работать с виртуальными таблицами, ограничения на соединения с виртуальными таблицами и очень много всего, что видимо ты считаешь бредом)))
---
ты сам то пробовал на практике это? Прежде, чем тыкать в книжки, попробуй на больших данных свои тыки. И рекомендации это рекомендации, на практике все может оказаться совсем иначе. И поднимать гигабайты данных, чтобы поперекладывать их по временным таблицам неведомая роскошь.
П.С. иди и почитай ИТС, а потом на больших данных опробуй различные варианты и удивись.
П.С.С. Секс в теории и на практике сильно отличаются
---
Хорошо. Объясняю теорию

Таблица остатков.
заказ1 15 20
заказ1 11 30
заказ2 15 20
заказ2 15 20
.....................
заказN 15 20

Чтобы всю ее не фильтровать мы используем отбор по измерению заказ (это как раз когда в параметрах виртуальной таблицы указываем Заказ = &МойЗаказ

Измерения регистров индексируются, поэтому этот отбор работает быстро.

Теперь представляем, что у нас не Заказ = &МойЗаказ а Заказ В (&МассивМоихЗаказов)

теперь чтобы системе установить отбор нужно виртуальную таблицу обработать (находить нужное умеет только по индексу или перебором. Как придумали в бородатых годах со времен баз данных так ничего нового и не придумали. Перебираем строки или ищем по индексу)

Так вот когда Заказ В (&МассивМоихЗаказов) тогда 90% это перебор т.к. хер знает что такое этот массив и он точно не проиндексирован. Т.е для каждой записи виртуальной таблицы он будет перебирать массив, чтобы выяснить ИзмерениеЗаказ = ЭлементМассива.

Когда заранее готовишь отдельную временную таблицу с отбором и индексируешь ее, то перебора может не возникнуть, а будет поиск по индексу (космос, супер, фантастика)

Еще нужно помнить, что реальный запрос к sql к виртуальной таблице не сводится к sel ect Fielt Fr om VirtyalnayaTablichka_name а имеет собственные левые соединения (план запросика надо посмотреть)

И реально на больших данных такие конструкции выигрывают в скорости (а иногда и в стабильности потому что планы запросов берут и меняются по воли sql), нооооооооооооооооооооооооо
Книжки это херня я уже понял. Нахер теорию и опыт умных дядек. Херню городят и 1ски разрабатывают
---
мда. реальный запрос к sql к виртуальной таблице не сводится к sel ect Fielt Fr om VirtyalnayaTablichka_name
Что правда что ли?

```1c
    SEL ECT
    T1.Fld4743RRef,
    T1.Fld4744RRef,
    T1.Fld4745RRef,
    T1.Fld7607_,
    T1.Fld4746Balance_,
    T1.Fld4747Balance_
    FR OM (SELECT
    T2._Fld4744RRef AS Fld4744RRef,
    T2._Fld4743RRef AS Fld4743RRef,
    T2._Fld4745RRef AS Fld4745RRef,
    T2._Fld7607 AS Fld7607_,
    T2._Fld4746 AS Fld4746Balance_,
    T2._Fld4747 AS Fld4747Balance_
    FR OM _AccumRgT4748 T2 WITH(NOLOCK)
    WH ERE T2._Period = @P1 AND (T2._Fld4746 <> @P2 OR T2._Fld4747 <> @P3)) T1
```

ВЫБРАТЬ
 ЗаказыНаПеремещениеОстатки.ЗаказНаПеремещение,
 ЗаказыНаПеремещениеОстатки.Номенклатура,
 ЗаказыНаПеремещениеОстатки.Характеристика,
 ЗаказыНаПеремещениеОстатки.КодСтроки,
 ЗаказыНаПеремещениеОстатки.ЗаказаноОстаток,
 ЗаказыНаПеремещениеОстатки.КОформлениюОстаток
ИЗ
 РегистрНакопления.ЗаказыНаПеремещение.Остатки КАК ЗаказыНаПеремещениеОстатки

Таблица(не виртуальная) регистра _AccumRg4742

Покажи мне, дураку, где тут не sel ect Fielt Fr om VirtyalnayaTablichka_name а имеет собственные левые соединения (план запросика надо посмотреть).
Я посмотрел.
---
Прошу прощения, что встреваю. Но почему Вы пренебрегаете поиском записей в таблице заказов, если по Вашим же словам там с вероятностью в 90% будет перебор? А также пренебрегаете временем создания новой виртуальной таблицы. И если же она создаваться не будет, а SQL превратит все это в собственные левые соединение, то зачем тогда индексировать по полю "Ссылка"?
---
Я думаю, что отдельно найти нужные ссылки в временной таблице быстрее (перебора вроде не должно быть, ссылка индексируется). Да это затраты, но я имел ввиду случаи, когда документов реально много. И всего лишь попросил попробовать, а не говорил, что это истинное решение. Вот только с ходу бредом назвали, даже не аргументируя.
---
бредом я назвал бездумное использование временной таблицы.
Аргументирую, чем плохо использование ВТ.
1. Затраты на ее создание и построение индекса
2. Оптимизатор запроса SQL совсем ничего не значет, что у него хранится в ВТ, это отдельный запрос.
3. При построении огромной таблицы выталкивается кеш, что негативно влияет на производительность.
4. Для чего создавать целую таблицу для единичной выборки данных.
Попробовал выбрать через В(&Массив). Index seek Это ни разу не перебор.
Опять же, часто использование временной таблицы обосновано задачей и данными.
---
Аргументы приняты)
хорошо, в этом случае отдельно в ВТ это не лучшая идея. (проверил 40 -100 заказов что так что так одинаково +- дестятысячные)
Все же думаю если заказов больше, такая конструкция имеет место быть
---
в любом случае, лучше взять таблицу шапок заказов, нежели взять их, положить в контейнер, и только потом связывать.
---
Возможно, но я тут уже по принципу
---
без индексирования в регистре на 8 раз выполнения запроса тратилось 2.7 секунды, сейчас на 8 раз выполнения запроса тратиться 0.18 сек, то есть стало отлично. Менять запрос уже нет смысла?
---
Позвновательные ответы