ВЫБРАТЬ
    ПродажиОбороты.Период КАК Период,
    Ном.Ссылка КАК Номенклатура,
    ПродажиОбороты.Подразделение КАК Подразделение,
    ЕСТЬNULL(ПродажиОбороты.КоличествоОборот, 0) КАК КоличествоОборот,
    ЕСТЬNULL(ПродажиОбороты.СтоимостьОборот, 0) КАК СтоимостьОборот
ИЗ
    Справочник.Номенклатура КАК Ном
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Продажи.Обороты(
                &Date1,
                &Date2,
                Месяц,
                Номенклатура В (&Номенклатура)
                    И Подразделение В (&Подразделение)) КАК ПродажиОбороты
        ПО (ПродажиОбороты.Номенклатура = Ном.Ссылка)
ГДЕ
    Ном.Ссылка В(&Номенклатура)

УПОРЯДОЧИТЬ ПО
    ПродажиОбороты.Номенклатура.Наименование
ИТОГИ
    СУММА(КоличествоОборот),
    СУММА(СтоимостьОборот)
ПО
    Номенклатура,
    Подразделение

а соединение зачем?

Нужно смотреть план запроса. Например можно вынести получение оборотов в отдельную ВТ.

(1) Не догадываешся? Видимо что бы получить обороты продаж по номенклатуре и нулевой оборот это тоже оборот.

"ГДЕ
    Ном.Ссылка В(&Номенклатура)"

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

(4) Как оптимизатор решит так и будет, нужно смотреть план запроса.

Вот это попробуй убрать
"Номенклатура В (&Номенклатура)"

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

соединение с виртуальной - переделать

(2) Спасибо, попробовал. Ощутимой разницы нет.

(4) Спасибо, попробовал. Ощутимой разницы нет.

(6) Спасибо, попробовал. Выполнилось на порядок медленнее.

(8) Что именно переделать?

(9) А как ты сделал (4) ? Сможешь показать код?

ВЫБРАТЬ
    Ном.Ссылка КАК Номенклатура
ПОМЕСТИТЬ тТовары
ИЗ
    Справочник.Номенклатура КАК Ном
ГДЕ
    Ном.Ссылка В ИЕРАРХИИ(&Номенклатура)
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ПродажиОбороты.Период КАК Период,
    ПродажиОбороты.Подразделение КАК Подразделение,
    ПродажиОбороты.Номенклатура,
    ЕСТЬNULL(ПродажиОбороты.КоличествоОборот, 0) КАК КоличествоОборот,
    ЕСТЬNULL(ПродажиОбороты.СтоимостьОборот, 0) КАК СтоимостьОборот
ПОМЕСТИТЬ тПродажи
ИЗ
    РегистрНакопления.Продажи.Обороты(
            &Date1,
            &Date2,
            Месяц,
            Номенклатура В ИЕРАРХИИ (&Номенклатура)
                И НЕ Контрагент В ИЕРАРХИИ (&СобственныеКонтрагенты)) КАК ПродажиОбороты
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ПродажиОбороты.Период КАК Период,
    ПродажиОбороты.Подразделение КАК Подразделение,
    ЕСТЬNULL(ПродажиОбороты.КоличествоОборот, 0) КАК КоличествоОборот,
    ЕСТЬNULL(ПродажиОбороты.СтоимостьОборот, 0) КАК СтоимостьОборот,
    тТовары.Номенклатура
ИЗ
    тТовары КАК тТовары
        ЛЕВОЕ СОЕДИНЕНИЕ тПродажи КАК ПродажиОбороты
        ПО тТовары.Номенклатура = ПродажиОбороты.Номенклатура

УПОРЯДОЧИТЬ ПО
    ПродажиОбороты.Номенклатура.Наименование
ИТОГИ
    СУММА(КоличествоОборот),
    СУММА(СтоимостьОборот)
ПО
    Подразделение

(11) Для (10)

(11) Пропустил индексирование во временной таблице

(13) Само проиндексируется как надо.

(14) Первый раз слышу

(13) Добавил индекс. Скорость не изменилась.

(16) Тогда некуда дальше оптимизировать :) имхо

(15) ИНДЕКСИРОВАТЬ ПО навредить гораздо легче, чем помочь. Достаточно указать неправильный порядок индексирования полей - и получишь тормоза. Не укажешь ИНДЕКСИРОВАТЬ ПО или укажешь правильный порядок - получишь одинаковую скорость в большинстве случаев.

(16) Что и требовалось доказать.

в параметрах вирт таблицы замени
Номенклатура В ИЕРАРХИИ (&Номенклатура)
на выборку из временной таблицы.
"в иерархии" тяжелая операция.
она у тебя два раза выполняется.

(11) Зачем тебе "Номенклатура В ИЕРАРХИИ (&Номенклатура)"

Если ты уже получаешь все в ВТ "тТовары" :)

(16) индекс по какому полю добавил?

(19) В реальном запросе так оно и есть. См (0).

"В иерархии" это что бы в консоли проверить.

(0) А какое время выполнения запроса?

юзай физическую таблицу РегистрНакопления.Продажи

(11) Почему
"УПОРЯДОЧИТЬ ПО
    ПродажиОбороты.Номенклатура.Наименование"
А не "тТовары.Номенклатура.Наименование"? К быстродействию отношения не имеет, но всё же.

(25) Зачем сортировка, если уже он сортирован?

(26) Кто сортирован?

измерения и порядок их у регистра какие?

(27) По моему при соединении по полю Номенклатура это поле сортируется. К тому же если в регистре у реквизита стоит "Индексировать"

(0) за какой период делаешь? долго это сколько?

(14) >> Само проиндексируется как надо.
а можно поподробнее? Как оно само по себе проиндексируется? Где почитать?

(29) Да ну, нет такого.

(32) Не знаю как толковать Гилева, но он так и написал:

Поиск, при котором данные считываются в определенном порядке. Если результирующий набор данных должен быть отсортирован в порядке кластеризованного индекса, то сортировка не нужна, поскольку результирующий набор данных уже заранее отсортирован. Например, если кластеризованный индекс создан по колонкам lastname (фамилия), firstname (имя), а для приложения требуется сортировка по фамилии и затем по имени, то здесь нет необходимости добавлять инструкцию ORDER BY.
Правда при всей полезности индексов, есть одно очень важное НО – индекс должен быть «эффективно используемым» и должен позволять  находить данные с использованием меньшего числа операций ввода-вывода и объема системных ресурсов.

В запросах кода конфигурации использование индексов зависит условий, на которые есть смысл обратить внимание:

ВЫБРАТЬ … ИЗ … ГДЕ <условие>
СОЕДИНЕНИЕ … ПО <условие>
ВЫБРАТЬ … ИЗ <ВиртуальнаяТаблица>(, <условие>)
ИМЕЮЩИЕ <условие>
Если в системе нет индекса, который мог бы эффективно использоваться для данного запроса, то необходимо рассмотреть одну из следующих возможностей:

Установить свойство «Индексировать»
Изменить порядок следования измерений в регистре

ветку не читал, но в запросе из (0) сортировать надо по наименованию из справочника, а не из регистра

(33) Может быть, это работает если выбирать данные из одной таблицы регистра накопления? Но в нашем примере же соединение. Если предположить что в таблице "тПродажи" пусто, то как результирующий набор данных отсортируется?

(35)+ после этого - возможно вынести виртуальную таблицу во временную + индекс по номенклатуре в ней, а её уже соединять со справочником

(36) Начнем с того что виртуальная таблица уже отсортирована. Или не согласен?

(0) явных косяков нет, так что без плана запроса - это гадание на кофейной гуще

Когда я вижу в запросе такие конструкции:
ПродажиОбороты.Номенклатура.Наименование
меня прям колбасит.

(38) Допустим. Но выбираешь строки ты из таблицы "тТовары", которая не отсортирована. А к ней присоединяешь отсортированную виртуальную таблицу. В честь чего в первой таблице изменится порядок строк? :)

(40) существенно не повлияет даже, если убрать совсем сортировку

(42) да ладно?

(43) наименование - это индекс. Ну, давай у автора спросим, чтобы не гадать.
АААВТООООР! Пробовал сортировку выкосить?

ВЫБРАТЬ БЫСТРО
  ПродажиОбороты.Период КАК Период,
...

(41) Ладно. У меня ща после соединения результат получился отсортированным без оператора сортировки

Можно местами поменять :
Подразделение В (&Подразделение)
                    И Номенклатура В (&Номенклатура)

(47) А может в регистре они так и расположены?

(48) Значит регистр тупой

(47) >> Можно местами поменять

Тогда уж лучше так:

(Подразделение, Номенклатура) В (ВЫБРАТЬ РАЗЛИЧНЫЕ &Подразделение КАК Подразделение, ВременнаяТаблицаНоменклатуры.Номенклатура КАК Номенклатура ИЗ ВременнаяТаблицаНоменклатуры КАК ВременнаяТаблицаНоменклатуры)

Вот людям заняться нечем

(0) еще раз, в чем вопрос стоит? долго это сколько? запрос выполняется не 3 секунды, а 15-20? для отчета это не существенно.

Стоит ли решение задачи потраченного времени?
Потому как сам запрос, как уже сказал (39), вполне правильно составлен.

без упорядочить и итоги скока формируется?

(31) Это опыт. Добавление ИНДЕКСИРОВАТЬ ПО чаще всего ничего не меняет (если грамотно добавлять), иногда ухудшает скорость до нескольких раз (если ошибся с индексами). Улучшения тоже бывают, но весьма редко - когда оптимизатор не справляется.

(54) т.е. Гилев не прав? Вот его мнение:

"Обратите внимание на то, что для оптимизации работы запроса почти всегда необходимо проиндексировать создаваемую временную таблицу. Индекс должен быть подобран таким образом, чтобы СУБД могла его использовать при соединении с временной таблицей. То есть, в индексе должны быть перечислены все поля, которые используются в условии соединения."

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

(54) имхо, просто объемы не те, чтобы увидеть разницу

(56) Ну раз автор решил постит эту ветку походу у него дохренище записей.

ВЫБРАТЬ ПОБЫСТРЕЕ

(59) волшебное слово забыл

(52) (56) Вот они правильные ответы.
"Оптимизировать код можно бесконечно, надо знать когда остановиться" (с) я не помню чьи слова, сорри

(0)
заменить ГДЕ на И
.....
        ПО (ПродажиОбороты.Номенклатура = Ном.Ссылка)
ГДЕ
    Ном.Ссылка В(&Номенклатура)



        ПО (ПродажиОбороты.Номенклатура = Ном.Ссылка) И
    Ном.Ссылка В(&Номенклатура)

(55) Вопрос в том, когда он это писал (для какой версии платформы). Плюс в некоторых сложных случаях прямое указание индексов может быть необходимо, но таких случаев немного.

А вот если сделать ИНДЕКСИРОВАТЬ ПО Организация, Подразделение, а потом используешь поля не в том порядке (типа, Подразделение = Подразделение И Организация = Организация) - то можно словить тормоза из-за того что индекс построить автоматом ты не дал, а сам указал тот индекс, который использовать не получится.

(57) 200 Гб база с сотнями тысяч-миллионами записей пойдет? Когда при неправильном указании индекса время выполнения запроса 20-30 секунд, а при правильном - около 1-2 секунд? Статистически разница между правильным индексированием и неуказанным индексом меньше 5% в большинстве случаев.

(62) Вылезет вся номенклатура.

(63) Ну тогда начерти бедному автору окончательный оптимальный запрос. И тему закроем

А вот если сделать ИНДЕКСИРОВАТЬ ПО Организация, Подразделение, а потом используешь поля не в том порядке (типа, Подразделение = Подразделение И Организация = Организация) - то можно словить тормоза из-за того что индекс построить автоматом ты не дал, а сам указал тот индекс, который использовать не получится.

Адская глупость

(65) Я тоже так думал, пока не столкнулся с тем, что запрос по 30 секунд выполнялся. Меняешь порядок условий через И, или порядок полей в ИНДЕКСИРОВАТЬ ПО - и все летает. Убираешь ИНДЕКСИРОВАТЬ ПО - тоже все летает, все зависимости от порядка условий.

Попробуй так:

ВЫБРАТЬ
    ЕСТЬNULL( тзПродажи.Период, &Date1 ) КАК Период,
    СпрНоменклатура.Ссылка КАК Номенклатура,
    ЕСТЬNULL( тзПродажи.КоличествоОборот, 0 ) КАК КоличествоОборот,
    ЕСТЬNULL( тзПродажи.СтоимостьОборот, 0 ) КАК СтоимостьОборот
ИЗ
    Справочник.Номенклатура КАК СпрНоменклатура

    ЛЕВОЕ СОЕДИНЕНИЕ ( ВЫБРАТЬ
        НАЧАЛОПЕРИОДА( Период, Месяц ) КАК Период,
        Подразделение,
        Номенклатура,
        СУММА( Количество ) КАК КоличествоОборот,
        СУММА( Стоимость ) КАК СтоимостьОборот
    ИЗ
        РегистрНакопления.Продажи
    ГДЕ
        Период МЕЖДУ &Date1 И &Date2
        И Номенклатура В ( &Номенклатура )
        И Подразделение В ( &Подразделение )

    СГРУППИРОВАТЬ ПО
        Номенклатура,
        НАЧАЛОПЕРИОДА( Период, Месяц ),
        Подразделение

    ) КАК тзПродажи
        ПО тзПродажи.Номенклатура = СпрНоменклатура.Ссылка
ГДЕ
    СпрНоменклатура.Ссылка В ( &Номенклатура )

УПОРЯДОЧИТЬ ПО
    СпрНоменклатура.Наименование

ИТОГИ
    СУММА( тзПродажи.КоличествоОборот ),
    СУММА( тзПродажи.СтоимостьОборот )
ПО
    СпрНоменклатура.Ссылка,
    тзПродажи.Подразделение

PS: Конфы как у тебя нет, проверить запрос не могу:

(67) Если таблицы толстые, то срочно "СпрНоменклатура.Ссылка В ( &Номенклатура )" заменить на внутреннее соединение!

(68) Думаю что это не поможет.
Так как во первых в начале идёт использование индекса периода, а уже потом идёт использование индекса связанного с номенклатурой.
Во вторых внутренним результирующий запрос будет уменьшен, что явно не в планах автора, как я понял ему нужна вся номенклатура из списка.

Изменённый запрос выглядит примерно так, но я не думаю что он будет быстрее:

ВЫБРАТЬ
    НАЧАЛОПЕРИОДА( ЕСТЬNULL( тзПродажи.Период, &Date1 ), Месяц ) КАК Период,
    СпрНоменклатура.Ссылка КАК Номенклатура,
    ЕСТЬNULL( тзПродажи.Количество, 0 ) КАК КоличествоОборот,
    ЕСТЬNULL( тзПродажи.Стоимость, 0 ) КАК СтоимостьОборот
ИЗ
    Справочник.Номенклатура КАК СпрНоменклатура

    ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Продажи  КАК тзПродажи
        ПО тзПродажи.Период МЕЖДУ &Date1 И &Date2
         И тзПродажи.Номенклатура = СпрНоменклатура.Ссылка
         И тзПродажи.Подразделение В ( &Подразделение )
ГДЕ
    СпрНоменклатура.Ссылка В ( &Номенклатура )

СГРУППИРОВАТЬ ПО
    СпрНоменклатура.Ссылка,
    НАЧАЛОПЕРИОДА( ЕСТЬNULL( тзПродажи.Период, &Date1 ), Месяц ),
    тзПродажи.Подразделение

УПОРЯДОЧИТЬ ПО
    СпрНоменклатура.Наименование

ИТОГИ
    СУММА( тзПродажи.КоличествоОборот ),
    СУММА( тзПродажи.СтоимостьОборот )
ПО
    СпрНоменклатура.Ссылка,
    тзПродажи.Подразделение

почему условие
СпрНоменклатура.Ссылка В ( &Номенклатура )
суете в ГДЕ, а не ПО?


ЗЫ
не понимаю, честно.

"НУ ПОЖАЛУЙСТА" в конце запроса забыли

До соединения идёт фильтрация номенклатуры ( СпрНоменклатура ), далее происходит соединение с регистром накопления ( тзПродажи ), в начале большую таблицу отсекает по периоду, ну а далее уже идёт урезание до нужных номенклатур в строке

И тзПродажи.Номенклатура = СпрНоменклатура.Ссылка

(72) "До соединения идёт фильтрация номенклатуры ( СпрНоменклатура )" - это где?

ИЗ
    Справочник.Номенклатура КАК СпрНоменклатура

ГДЕ
    СпрНоменклатура.Ссылка В ( &Номенклатура )

Это отрабатывает первым оптимизатором запроса

далее идёт соединение

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

Проверьте скорость выполнения двух моих запросов на ( холодных данных )

да в первом запросе нужно подправить на:

ЕСТЬNULL( тзПродажи.Период, НАЧАЛОПЕРИОДА( &Date1, Месяц ) ) КАК Период,

вместо:

ЕСТЬNULL( тзПродажи.Период, &Date1 ) КАК Период,

Если можно урезать главную таблицу до соединения, то оптимизатор, я думаю, это сделает, во всяком случае для MSSQL это так, для файловой я думаю что это примерно так же

(77) Вот здесь для тех, кто блондинки - кто такой оптимизатор? :)

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

(79)
проверил бы, для начала.
(78)+1

(80) Нет конфы предлагаю проверить самим, я и так уже в рот положил, а челюстями поработайте пожалуйста сами.

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

И вот такой вариант:
ВЫБРАТЬ
    СотрудникиОрганизаций.Ссылка
ПОМЕСТИТЬ ВТ_Сотрудники
ИЗ
    Справочник.СотрудникиОрганизаций КАК СотрудникиОрганизаций
ГДЕ
    СотрудникиОрганизаций.Ссылка В(&МассивСотрудников)
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ВТ_Сотрудники.Ссылка,
    РабочееВремяРаботниковОрганизацийОбороты.Организация,
    РабочееВремяРаботниковОрганизацийОбороты.ДнейОборот
ИЗ
    ВТ_Сотрудники КАК ВТ_Сотрудники
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.РабочееВремяРаботниковОрганизаций.Обороты(&НачалоПериода, &КонецПериода, Период, Сотрудник В (&МассивСотрудников)) КАК РабочееВремяРаботниковОрганизацийОбороты
        ПО ВТ_Сотрудники.Ссылка = РабочееВремяРаботниковОрганизацийОбороты.Сотрудник

+(82) В первом варианте таблица СотрудникиОрганизаций тупо тащит ВООБЩЕ ВСЕ записи из справочника, а во втором ВТ_Сотрудники имеет уже только то, что отобрано условием

База у меня файловая естественно. Но вывод для меня совершенно однозначный: условия в запросах отрабатывают ПОСЛЕ соединения таблиц

(84)
в скуле то же самое.
чудес не бывает.(с)

(84) а как же Великий Оптимизатор? он за нас не подумал и не отсек при объединении ненужные строки сотрудников?

а, у вас левое, тогда не отсек, не заметил =)

(86) не знаю, не могу посмотреть таблица после соединения, но до условия.
(87) так в (0) тоже левое, в том и соль, что ему весь справочник нужен

(88)
так вместо накладывания условия после объединения
ГДЕ
    Ном.Ссылка В(&Номенклатура)

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

(89) Эммм... человеку нужно, чтобы номенклатура вывелась даже если движений не было. Вероятно поэтому левое, а не внутреннее

ему весь справочник нужен

и

ГДЕ
    Ном.Ссылка В(&Номенклатура)

никак не могу согласовать в голове две эти вещи

хорошо вбросил
а нужно ли его торопить?

(91) ну елки. Не весь справочник, а весь массив номенклатуры. Не придирайтесь к словам

(89) Нахрена тогда вообще с номенклатурой соединять если нужно тупо то что в обороте уменьшенное на список, а не полный список?

(90) Мадам, если пишется конструкция В (&Номенклатура), то это ничто иное как внутреннее соединение.

(89)
может и так. автор знает.

(94) +
Вот мы и приходим потихоньку к решению проблемы автора

(95) А если эта конструкция левым соединением к справочнику цепляется?

(95)
скорее всего, да.
но не всегда.
может оказаться, что в &Номенклатура присутствуют ссылки,
которых нет в справочнике (удалены).

(94) Нужно всю нужную номенклатуру вне зависимости от наличия/отсутствия оборотов по ней.
Вы чего? Уже отдыхаете?

(95) Оригинальная трактовка внутреннего соединения.

(94) А с номенклатурой соединять, видимо потому, что по списку нужны все обороты, в т.ч. нулевые, а в оборотах их нет.

И вообще, чего я распинаюсь? Накинулись, блин. Грузите мозг ТСу, это его проблемы

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

(100)+1
(99) сторно.

(99)>>может оказаться, что в &Номенклатура присутствуют ссылки,
которых нет в справочнике (удалены).

Случайно забрели из другой базы?

(103) Ну вот, первая здравая мысль за всю ветку.

(100) Вот, мы уже начали ванговать что собственно ТС хотел получить данным запросом =)

(100) Нет я то как раз в курсе что нужно и 2 моих запроса говорят об этом

(105)
удалили программно.
ну, может движения и "Случайно забрели из другой базы".

(108) Да, мы с вами обсуждали лишь последовательность действий :)

(98) Не имеет значения, просто подумайте, что значит "В()". (99) Не будем на столько извращаться :)

(89) По поводу ГДЕ в запросе с фильтрацией номенклатуры. Кто нибудь может привести план исполнения запроса в MS SQL чтобы явно показать что номенклатура фильтруется после соединения а не до

(106) Не первая :) см 52, 56, 61

(111) Я прям замер во внимании, про левое соедение я уже узнал много нового осталось получить альтернативное знание по оператору В

(0) стандартные советы испробовал: вирт. таблицу поместить во временную с индексом, убрать использование реквизитов через точку (в сортировке) и т.д.?

странно, что еще никто про агрегаты не вспомнил

(112) в методичках юзай, найдешь

(111) ЧЕго вы ко мне прицепились?

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

83% времени выполнения уходит на поиск по кластерному индексу по таблице оборотов. Вы жжете ребятушки, что до сих пор профайлер не запустили.

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

Время выполнения в секундах уже озвучивали?

Вот эта строчка

|--Clustered Index Seek(OBJECT:([testbase].[dbo].[_AccumRgTn19349].[_Accum19349_ByDims_TRRRRRRRRRN] AS [T3]), SEEK:([T3].[_Period] > [Expr1047] AND [T3].[_Period] < [Expr1048]),  WHERE:([testbase].[dbo].[_AccumRgTn19349].[_Fld19329RRef] as [T3].[_Fld19329RRef]=[@P3] AND [testbase].[dbo].[_AccumRgTn19349].[_Fld19334RRef] as [T3].[_Fld19334RRef]=[@P4]) ORDERED FORWARD)

Непонятно вот это:

WHERE:([testbase].[dbo].[_AccumRgTn19349].[_Fld19329RRef] as [T3].[_Fld19329RRef]=[@P3]

Ибо Номенклатура идет сразу за периодом в кластерном индексе.

(115)
так вроде это уже предлагали, не?

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

УПОРЯДОЧИТЬ ПО
    ПродажиОбороты.Номенклатура.Наименование

и т.д.

а про добавить агрегаты с нужными измерениями и периодичностью кто-нибудь вспомнил? кто-нибудь ими вообще пользуется? ;)

(125) да, ты немного опоздал; теперь ждем ТС

(125) в уже работающей базе накрутить агрегаты разве кошерно?

(122) Ты можешь план исполнения моих двух запросов привести?

(127) ну там же есть функции типа

РегистрНакопленияМенеджер.<Имя регистра накопления>.ОпределитьОптимальныеАгрегаты (AccumulationRegisterManager.<Имя регистра накопления>.DetermineOptimalAggregates)
РегистрНакопленияМенеджер.<Имя регистра накопления> (AccumulationRegisterManager.<Имя регистра накопления>)
ОпределитьОптимальныеАгрегаты (DetermineOptimalAggregates)
Синтаксис:

ОпределитьОптимальныеАгрегаты(<МаксимальныйОтносительныйРазмер>)
Параметры:

<МаксимальныйОтносительныйРазмер> (необязательный)

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

Тип: ИнформацияОбАгрегатах.

Описание:

Выполняет построение оптимальных агрегатов.

Доступность:

Сервер, толстый клиент, внешнее соединение.