УТ10.3 У кого проблемы со скоростью списания партий, ходь сюды
 

УТ10.3, файловый вариант (на скуле не проверял, но скорее всего то же самое, хотя может и нет, скуль ведь умнее одноэски :) )
Если включен учет партий по складам, то делаем следующие:

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

Ну и по аналогии тоже самое в процедурах:
ЗаполнитьЗапросПартийНаСкладахДляОтложеннойОтгрузкиУпр
ЗаполнитьЗапросПартийНаСкладахДляСписанияПоОрдернойСхемеУпр

У меня сорость проведения документов реализация увеличилась раз в 30, ибо индексы заработали :)

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

На скуле наоборот будет медленнее работать, по идее - это ж вложенный запрос с объединением.
То, что движок исполнения запросов в файловой 1С не использует индексы по конструкциям вида "Реквизит = &Значение1 ИЛИ Реквизит = &Значение2" - это избитый баян. Для скуля же все зависит от наполненности индекса по этим измерениям: сканить или использовать индекс. В файловой базе, очевидно, никакой статистики нет.
Кроме того, очень странно говорить об использовании индекса по складам, когда у нас в начале идет индекс по номенклатуре. Сколько же у вас в базе складов по сравнению с номенклатурой? Если система действительно получает выигрыш от поиска по двум значениям, нежели от скана. Тем более, что сначала идет опять же сложное наложение условия по номенклатуре. При небольшой плотности индекса оптимизатор SQL даже игнорирует индекс по сотням позиций номенклатуры... А тут - склады, коих в базе обычно несколько штук.
ПЫСЫ: В MS SQL статистика индекса ведется только по первому измерению составного индекса. Так что тут оптимизатор может косячить с использованием индекса позря. Может это 1С его так подстегивают.

2-Lexusss >Я не знаю, чего там одинэска думает в файловом режиме, какой там план - не понятно.
Там же ведь кроме составного индекса есть ещё персональные индексы на Номенклатура и Склад.
Так что тёмный лес, чего она там крутит :)

1-angro >Комплексно :)

(3) Ты скажи, сколько у тебя разных складов и сколько номенклатуры в таблице остатков?

5-Lexusss >Номенклатуры - 20642, складов 25.

Реально помогло. Причем именно в SQL базе. Спасибо !!!