Ускорить получение остатков #703625

Приветствую! Подскажите, можно ли каким-то образом ускорить получение остатков при проведении? РЕГИСТР НАКОПЛЕНИЯ "ОстаткиТоваров" (порядок измерений и ресурсов сохранен): Измерения - Номенклатура (+Индексировать) `около 100'000 наименований - Подразделение `около 20 штук

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

провести пересчек итогов на SQL - помогает. Проверить как закрыты регистры

это Тестирование и исправление через конфигуратор? Или как-то прям через SQL?

да, это ТиИ, но вряд-ли поможет, хотя...

а просто запрос по остаткам быстро или медленно формируется?

1.сделать второй запрос в пакете в котором отбирать из первого в отдельную таблицу номенклатуру, подразделение, организацию. 2.в условии на ВТ Остатки переписать на (Номенклатура, Подразделение, Организация) В (Выбрать ВТТовары2.Номенклатура, ВТТовары2.Подразделение, ВТТовары2.Организация ......)

да, ТиИ пробовали - не помогает. если просто в консоли выполнить этот запрос = 0.047, если убрать соединение с товарным чеком и оставить только по остаткам = 0.015 это, конечно, наверное даже быстро, но просто заказчик когда массовым перепроведением занимается - говорит "хочу быстрее, оптимизируйте!", а мы уже месяц в ответ говорим что дальше уже некуда оптимизировать)

ну так пусть железо апгрейдит

ага, массовое проведение занимается большей частью этим запросом, да?

если всё правильно понял - попробовал, тратится чуть больше времени, чем на изначальный сделал замер производительности - больше 30% времени тратится на этот запрос

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

Попробуй в ВТ проиндексировать по "Номенклатура" + возможно, надо замерять еще и "КатегорияТовара".

Засунь отбор по категории товара в виртуальную таблицу |                (Номенклатура, КатегорияТовара) В |                        (ВЫБРАТЬ

Таблицу ВТ проиндексируй по Номенклатуре и Категории товара, хотя если в документах реально по 2-3 строки то вряд ли поможет.

Поищи добавленные умельцами подписки на события документа ПриЗаписи, ОбработкаПроведения. Если кривые - оптимизируй.

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

нет, нужно что-бы отбор был по первым, т.е. если измерения 1,2,3 то отбор по измерениям 1 + 2 - нормально, а если 2 + 3 - индекс ничем не поможет

сверху = по первым, не так выразился. но ведь все ок?

ок, так и сделаем. Ладно, всем спасибо(!), если ни у кого больше замечаний нет, то "теперь мы точно сделали всё что могли")

а использование итогов регистров выключали перед перепроведением?

смысл оптимизировать этот запрос, если дело не в запросе

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

Как определил что дело не в запросе?

соотнеси время выполнения запроса со временем  проведения документа...

Если отключить итоги, то как получить остатки?

я не утверждал, что дело в запросе, просто привел и регистр и запрос, и спросил мысли людей)

хотя да.. тут не прокатит

не те объемы для индексирования

При проведении документа могут быть десятки обращений к СУБД, никто не говорит что время выполнения запроса и время проведения документа будут совпадать.

я к тому, что это может не самое узкое место. Замер производительности делался?

1. Выполнили средствами 1с (через конфигуратор) полный пересчет итогов. 2. Выполни перестроение индексов и обновление статистики на SQL сервере. PS странно, зачем в регистр остатков добавили измерение Организация.

RLS используется?

да, писал выше, что больше 30% времени всего перепроведения тратиться на этот запрос..

а 2ой пункт именно на SQL сервере надо? Галочка о переиндексации в конфигураторе в Тестирование и исправление - не то?

RLS не используется

Я бы лично поймал бы этот запрос в профайлере и покрутил бы его в студии. Проверил бы на хинты по индексам, на планы выполнения...

На мой взгляд, запрос вполне корректный. Как вариант я бы попробовал сделать без временки.

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

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

При списании товара по-средней себестоимость не изменяется. Для того, чтобы узнать остаток на момент текущего документа - зачем выполнять запрос к таблице остатков, если известен остаток на начало предыдущего документа и известно, на сколько он уменьшился?

Проще тогда на РАУЗ пересесть