Имеется регистр накопления указанной структуры, требуется ответить на вопросы и обосновать

ТоварыНаСкладах(Измерения:склад, номенклатура,ХарактеристикаНоменклатуры,СерияНоменклатуры,Качество
Ресурсы:Количество, КоличествоЛ)


1)

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


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


3)

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



1)В чем отличие этих запросов с точки зрения производительности?
2)Как добиться оптимальности выполнения этих запросов?
3)Какова логика выполнения данных запросов в СУБД?
4)Какой регламент должен соблюдать администратор базы, чтобы подобные запросы выполнялись наиболее оптимально?

Как вариант:
1) Нужно использовать максимально параметры виртуальных таблиц, сначала выбираются данные для виртуальных таблиц, а потом уже на них накладываются условия, соединения и т.д.
2) В случае, когда необходимо вывести лишь текстовое представление объекта нужно использовать функцию ПРЕДСТАВЛЕНИЕ(<Выражение>)
запрос в этом случае будет оптимальным, т.к. не будет создаваться дополнительная таблица.

Коллеги, прошу советов или что можно почитать по этому поводу, особенно по вопросам 3 и 4.

(2)почитайте свои институтские лекции .

https://its.1c.ru/db/metod8dev#content:5842:hdoc

1) Все запросы, кроме 2 - "неоптимальны" в рамках очевидности, так как не будут использовать поиск по индексу.
2) Передвинуть номенклатуру на первое место в измерениях. Этого достаточно. Номенклатура обеспечит достаточную селективность выборки.
3) Логика простая. Кластерный индекс используется тогда, когда в полях поиска нет пропусков, начиная с первого поля-измерения.
4) Обновление статистики, сброс процедурного кэша и дефрагментация индексов.

Отряд не заметил
Потери бойца
И «Яблочко»-песню
Допел до конца.
Лишь по небу тихо
Сползла погодя
На бархат заката
Слезинка дождя...

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

(7) Складов мало.

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

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

Ты не прав.

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

Коллеги, огромное спасибо за ответы, буду работать в этом направлении и штудировать материалы по данным вопросам.