Коллеги, нужна экспертная помощь.
Получаю остатки из таблицы

ВЫБРАТЬ
  ТоварыНаСкладахОстаткиИОбороты.Номенклатура,
  ТоварыНаСкладахОстаткиИОбороты.КоличествоКонечныйОстаток
ИЗ
   РегистрНакопления.ТоварыНаСкладах.ОстаткиИОбороты(ДАТАВРЕМЯ(2013, 11, 1, 0, 0, 0),   ДАТАВРЕМЯ(2013, 11, 3, 23, 59, 59), ДЕНЬ, , ) КАК ТоварыНаСкладахОстаткиИОбороты

В профайлере в таком случае вижу ОГРОМНЕЙШЕЕ количество следующих записей (все они в транзакции):

RPCCompleted: exec sp_execute 2,'4013-11-03 00:00:00',0x85E1080027419A6711E19039E63E0E6C,4.000

Table Insert(OBJECT:([tempdb].[dbo].[#tt1]), SET:([tempdb].[dbo].[#tt1].[_Period] = [Expr1003],[tempdb].[dbo].[#tt1].[_Fld7737RRef] = [Expr1004],[tempdb].[dbo].[#tt1].[_Fld7741FinalBalance] = [@P3]), DEFINE:([Expr1003]=CONVERT_IMPLICIT(datetime2(0),[@P1],0), [Expr1004]=CONVERT_IMPLICIT(binary(16),[@P2],0)))

После всех подобных записей транзакция фиксируется, и в профайлере появляется "конечный" запрос формирования остатков по виртуальной таблице: данные уже берутся из той самой #tt1, что формировалась крайне долго.
Откуда такая неэффективность? Зачем 1С помещает каждую запись во временную таблицу?

Платформа 8.3.10.2580 (режим совместимости 8.3.8), mssql 12.0.5579

(0) Потому что такова физическая сущность виртуальной таблицы ОстаткиИОбороты и рекомендуется ее без нужды не использовать.
По факту Вы с начала получаете значение последнего расчитанного остатка, потом суммируются движения до даты К. Так получаются все реусрры за период

(1)  последнего расчитанного итога, ошибочка

И вообще использовать виртуальные таблицы РН, где данные будут получатся не из итогов, без отбора - не очень правильно

(1)  Однако, спасибо. Но я не думал, что при работе с этой вирт. таблицей все вот настолько плохо.

(3) Есть один неэффективный запрос. Решил разобраться и наткнулся на это. Не знал, что всё настолько грустно. При этом диск, где лежит tempdb, нагружается сильно если данных много.

(4) Уважаемый, в (3) ключевое слово "без отбора". Поставьте отборы и всё полетит ))  SQL это любит )

(5) Пользователям надо поставить отборы, например:
Склад В ИЕРАРХИИ()
Номенклатура В ИЕРАРХИИ()

И там большой перечень объектов.

В некоторых случаях еще по реквизитам! Так что полностью не соглашусь с необходимостью иметь отборы для того, чтоб летало -)

(5) "Поставьте отборы и всё полетит ))  SQL это любит )" отборы в вирт таблицах 1с? Хм.., а прмчем тут скуль?
Детализация "День" - со всеми вытекающими...

(6) вообще-то в учете всё берется за месяц, квартал, год. Поэтому таблица остатки обороты под это и заточено, чтобы максимально быстро выдавать отчеты по месяцам. отчеты по дням при этом выполняются максимально медленно

(0) используйте таблицу остатков на начало и реальную таблицу

анафейхоа получать остатки из ОстаткиИОбороты?

(3) Как же получать все остатки на дату, например?

(10) Присоединяюсь к вопросу.
Мало того, что остатки берутся с ОстаткиИОбороты, так еще и с периодичностью ДЕНЬ. А это означает, что даже при рассчитанных за ближайшие периоды итогах данные будут тянуться из таблиц первичных записей.

(6) > Пользователям надо поставить отборы

Отлично! Пусть ставят! А где эти отборы в тексте запроса? Почему в параметрах виртуальной таблицы нет ни одного отбора?

(12) Агрегаты должны помочь

(4) > при работе с этой вирт. таблицей все вот настолько плохо

Всё там нормально. Просто надо понимать как они работают и думать головой прежде чем писать текст запроса. Ну и не ждать чудес, если вам вдруг реально нужны и остатки, и обороты, и непременно за каждый день в выбранном периоде.

(14) Как агрегаты могут помочь в регистре остатков? Или что ты подразумеваешь под агрегатами в данном контексте?

А может ну её нафиг, виртуальную таблицу. Обороты по дням можно прекрасно сгруппировать запросом к таблице движений. МОжет и быстрее получится.

(16) Я думал, мы про выборку оборотов толкуем) Мозг зацепился за "ДЕНЬ" + "данные будут тянуться из таблиц первичных записей", а агрегаты в этом как раз и помогают.
Но не с регистром остатков, это да - не обратил внимания.

(17) В некоторых случаях так оно и есть. Зависит от конкретной задачи. Собственно говоря 1С так и делает, когда надо получить остатки и обороты в промежутках между периодами рассчитанных итогов (на середину месяца, например) - тащит данные из первичных таблиц.
Написание запроса к первичной таблице самостоятельно уменьшает окно свободы для оптимизатора скуля, который иногда начинает строить не самые оптимальные планы запросов.
Но это уже зависит от конкретного примера и целого ряда дополнительных условий (наличия дополнительные соединений, количества данных в источниках, порядка выборки, налагаемых отборов, индексов и пр. и пр.).
В реальной жизни редко имеет смысл опускаться до таких тонкостей и проще оставить самой 1С строить текст запроса, как ей нравится.

(10) Смысл такого запроса в том, чтобы именно "по дням" получить остатки.
(8) Я бы только ЗА, чтобы ваша теория не поддавалась опровержению. Но вот есть ситуацию, когда надо брать не от 01.05 по 01.06, а от 07.05 по 07.06
(13) Ну я не стал просто скидывать всё. Если необходимо для расследования или для интереса, могу сбросить.
(14) А вот на этот счет даже и не думал, агрегаты будут работать? (18)  Все правильно думали, именно периодичность ДЕНЬ и играет в этом случае важную роль. Мне не нужны обороты, мне нужны остатки по дням. (так уж сложился исторически имеющийся запрос, поэтому настаиваю)

(15) Вот чего чего, но я таки нигде не нашел инфу о том, что записи помещаются во временную таблицу. Можете об этом что-то рассказать? Или где об этом почитать, что при использовании вирт. таблицы ОстаткиИОбороты с установленной периодичностью будет задействована временная таблица?

Почуствуй разницу :)

ВЫБРАТЬ
  ТоварыНаСкладахОстатки.Номенклатура,
  ТоварыНаСкладахОстатки.Остаток
ИЗ
   РегистрНакопления.ТоварыНаСкладах.Остатки(&ДАТА_1,   &ДАТА_2, ДЕНЬ, , ) КАК ТоварыНаСкладахОстатки

(22)+ немного соврал?

(0) зачем тебе остатки по дням нужны? дай более развернутый запрос

(22) У вирт. таблицы Остатки только 2 параметра, не прокатит к сожалению.

(23) > зачем тебе остатки по дням нужны? дай более развернутый запрос
Нужно анализировать простои товарных запасов. Запрос отчета передавался из поколения в поколение и дошел до меня, поэтому пока настаиваю на использование ОстаткиИОбороты.

(24) >>>Нужно анализировать простои товарных запасов

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

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

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

(25)
2) По дням вряд ли будет быстрее. А вот разить номентклатуру кусками по 100-1000 и сделать это в цикле - вот это да.
3) Вариант кстати, и еще конечной остаток,, может и взлететь, но надо тестировать.
Имхо разить большой запрос на запросы в цикле - будет лидером по скорости, но это не точно.

Но надо помнить, что если будет отбор по измерению - то в таблице остатков и оборотов идет обращение к реальной таблице и рекомендую у этого измерения поставить галочку Индексировать. Ибо у реальной таблицы индекса по [ОРРХ | ОРНР1 +] Измерение + Период +.... нет. И как показала практика это существенно ускоряет работу в запросах к вирт таблице ОстаткиИОбороты с отбором

Перефразирую, выше коряво:
Но надо помнить в таблице остатков и оборотов идет обращение в том числе и к реальной таблице, и если будет отбор по измерению - и рекомендую у этого измерения поставить галочку Индексировать. Ибо у реальной таблицы индекса по [ОРРХ | ОРНР1 +] Измерение + Период +.... нет. И как показала практика это существенно ускоряет работу в запросах к вирт таблице ОстаткиИОбороты с отбором

(20) Не, агрегаты только для оборотных регистров можно сделать :( Хотя почему их не сделали для остаточных, чтоб они использовались при получении остатка в тех случаях, когда применяется основная таблица (чтоб применялась не основная таблица, а агрегаты по дням / неделям, например) - не ясно

(29) Пришла в голову мысль, что можно самому "воссоздать" агрегат для остаточного р/н - создать р/с по необходимым измерениям, один из которых - это период (день).

Всем спасибо.

(30) Проще уж тупо транслировать остаточный РН в новый "чисто оборотный" с включенными для него агрегатами, не?

(0) Я очень извиняюсь, но надеюсь, что обслуживание базы выполняется регулярно?

(31) Согласен, я так частенько делаю и это дает свои плоды

(31) > транслировать остаточный РН в новый "чисто оборотный" с включенными для него агрегатами, не?

Спорный вопрос, зависящий от конкретных условий его использования и требований. Для ускорения запросов и отчетов наличие такого оборотного регистра будет полезным. Но только там, где мы руками пропишем получение оборотов из него.
А вот заполнение этого регистра поднимает вопрос производительности при записи. Если только актуальность этого регистра не требуется online и можно вынести его заполнение за рамки проведения (что-то типа отложенного заполнения).