Здравствуйте, вот прочитал статью http://1cexpo.ru/metodiki/20-tipichnye-prichiny-neoptimalnoj-raboty-zaprosov-i-metody-optimizaczii.html и есть один вопрос, думаю тут быстрей всего ответят
Есть запрос

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

В данном случае нарушено требование 3. Между измерениями «Склад» и «Качество» в структуре регистра находится измерение «Номенклатура», которое не задано в условии запроса. Этот запрос так же не сможет выполняться оптимально. При его выполнении СУБД выполнит поиск по первому полю индекса, но затем вынужденно просканирует некоторую его часть. Сканирование приведет к увеличению времени выполнения запроса и к блокировке избыточных записей в таблице, то есть к снижению общей пропускной способности системы.

Варианты оптимизации:

   Добавить в запрос условие по измерению «Номенклатура»
   Убрать из запроса условие по измерению «Качество»
   Перенести «Номенклатуру» из измерений в реквизиты
   Поменять местами измерения «Номенклатура» и «Качество

И запрос

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

В этом случае требования соответствия индекса и запроса не нарушены. Данный запрос будет выполнен СУБД оптимальным способом. Обратите внимание на то, что порядок следования условий в запросе не обязан совпадать с порядком следования полей в индексе. Это не является проблемой и будет нормально обработано СУБД.

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

какие-то придурки. А если нужно по всей номенклатуре получить остатки?

(1) сам такой. Рекомендации дельные.

(2) ну вот, допустим, мне нужно получить остатки товаров на складе? Я должен по-твоему залезть в конфигуратор и перенести в регистре номенклатуру из измерений в реквизит? Это дельно?

(3) Реквизит ? Оо тут же обращение к виртуальной таблице

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

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

(5) Измерения

(4) ну тогда остается вариант вставить всё-таки в запрос условие Номенклатура = &Номенклатура и запустить в цикле.

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

(8) за такое надо руки отрывать

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

(6) Можно поподробнее?

(3) ты что-то не так понял из рекомендаций.

(10) Индексы в упрощенном виде строятся так:
Измерение1
Измерение1+2
Измерение1+2+3... и т.д.

Потому если пропустить 2 измерение отбор пойдет по индексам только по 1 измерению, а для 3 будет сканирование.

(5) реквизиты можешь менять как хочешь, они не индексируются

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

читаем буквари по sql...

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

(14) измерения, опечатался, см (7)

(17) да, менять местами порядок измерений чревато.

насколько я знаю, индексы в таблице остатков регистра накопления строятся следующим образом:
Период + Измерение1 + ... + ИзмерениеN + Разделитель
и если опираться на теорию по индексам, то можно сказать таким образом, т.к. измерения идут в порядке Склад, Номенклатура, Качество и т.д. (исходя из ссылки), то прекрасно можно представить, что при использовании отбора на Склад и Номенклатуру мы точно получим положение указателя с которого нам надо сканировать для поиска...
В случае когда мы будем устанавливать отбор по Складу и Качеству, то в таком случае SQL не сможет точно определить такое соответствие в индексе и следовательно, он поставит указатель для поиска в ту точку, где начинается именно такой Склад, а все остальное будет сканироваться и сравниться на условие отбора по качеству.
Короче говоря, при использовании композитного индекса возможно их использовании только при условии, когда накладывается отбор последовательно (т.е. так, как задано в конфигураторе)

(13) а сканирование имеется ввиду без индекса поиск что ль?

(+19) ну и Измерение + Период

копипаста с ИТС

Требования к индексу, перечисленные в рекомендациях, связаны с физической структурой индекса в СУБД. Эта структура представляет собой дерево значений проиндексированных полей. На первом уровне дерева находятся значения первого поля индекса, на втором - второго и так далее. Такая структура позволяет достичь высокой эффективности при поиске по индексу. Кроме того, она гарантирует отсутствие деградации производительности индекса с ростом количества данных.

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

(13) Неправ, так строятся только индексы для тех таблиц, в которых либо нет индексированных полей, либо только первое поле индексировано.
Пример для РС
Строится индекс
ИзмерениеN + Измерение1 + [Измерение2 +...]    
ЕСЛИ Измерению "ИзмерениеN" задано свойство "Индексировать" или свойство "Ведущее" и при этом это не первое и не единственное измерение.
Индекс, включающий все измерения. Первое поле - ИзмерениеN, затем все остальные измерения в том порядке, в котором они заданы при конфигурировании.

Вопрос автору, для чего он выполняет запрос и что предполагается дальше с ним делать, в рамках какой задачи?

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

тупая реклама статьи...

забаньте автора за спам

(24) вопрос для общего развития, после прочтения статьи возникли вопросы

(24) нормальный вопрос... исходя из этого можно проектировать регистр накопления, например )

(20) Один из видов обхода таблиц плана запроса, в моем контексте имелось ввиду методы обхода не использующие индексы.

(26) если бы не скинул ссылку, уже б начали орать что скопипастил без ссылки, и тд.

(27) не всякое сканирование вредно,
а лишь то, что наложит блокировку

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

Тоесть в данном примере поиск идет так:
Ищет в: Склад,
Потом в:Склад+Номенклатура,
Потом в:Склад+Номенклатура+Качество
и так для каждого параметра? правильно?

http://www.sql.ru/articles/mssql/03013101indexes.shtml
вот почитай

индекс это как правило дерево

номенклатура 1
  - склад 1
      - качество 1
  - склад 2
      - качество 2

номенклатура 2
  - склад 1
  - склад 2

есть сканы которые не накладывают блокировку? это как?

(34) Пасиб, интересно и не заумно