Доброго всем!
Буквально сегодня читал статью о том, как один чувак сдавал спеца по платформе. И там у него промелькнула фраза "желательно использовать пакетные запросы вместо вложенных, и индексировать". Ниже был приведен пример кода:

"ВЫБРАТЬ
| РасходнаяНакладнаяСписокНоменклатуры.Номенклатура КАК Номенклатура,
| РасходнаяНакладнаяСписокНоменклатуры.Свойство КАК Свойство,
| РасходнаяНакладнаяСписокНоменклатуры.Количество
|ПОМЕСТИТЬ ВремТаб
|ИЗ
| Документ.РасходнаяНакладная.СписокНоменклатуры КАК РасходнаяНакладнаяСписокНоменклатуры
|ГДЕ
| РасходнаяНакладнаяСписокНоменклатуры.Ссылка = &Ссылка
|
|ИНДЕКСИРОВАТЬ ПО
| Номенклатура,
| Свойство
|;

Честно говоря никогда этим не пользовался. Попытался найти на "Я", но чего-то вразумительноге не увидел. Можете объяснить в каких ситуациях НЕОБХОДИМО применять "ИНДЕКСИРОВАТЬ ПО". Каким образом это повлияет на производительность?!

Херово повлияет

(1) а более развернутый ответ можно?!

Имеет смысл, когда
1) Таблица велика (больше 1000 строк)
2) Индексируемое поле малоселективно.
3) Таблица используется несколько раз

Если не выполняются первые 2 условия - индекс использоваться не будет.

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

Неуспел

Да твою ж... Ежик, ты сегодня постоянно меня обгоняешь :-)

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

Меня сегодня жена разбудила в 7 утра и сказал - "пошел работать, животное, я давно уже встала (ага, у них там 10 утра уже)". Вот, изливаю злость.

(7) возвращайся на рынок СП торговать :)

(9) а жена где?

И еще полезно,  когда используется НЕОДНОКРАТНО как таблица левого соединения. Например, куча запросов с объединением, а уточняющие данные неиндексированны.  
Я применял для расчетов по бюджетной модели.

(10) Этот рынок уже теряет привлекательность... Спрос падает, накладные растут... :-(

Допустим у меня есть Рег Сведений непериодический с большим количеством записей. У него 3 измерения. Одно из измерений составного типа с большим количеством возможных типов. Обращаюсь я к нему довольно часто (использую в работе часто). Имеет смысл индеквировать?!

(14) Мы счаст говорим про временные таблицы или про физические?

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

(15) мммм....ну в конкретном случае про физические.

Лучшая проверка теории это практика.

(15) Временные - они тоже физические :-0

(3) "2) Индексируемое поле малоселективно. "
это как?

(3) Хм. Енмип при малоселективном индексе скуль все равно будет сваливаться в tablescan. Не?

(20) Например, склад. Отбор по складу выбирает больше 3 данных.

(21) Нет

Помогите понять индексы MS SQL

Правильные ответы в (44) (47) (53)

(23) Уточню, если индекс будет по 1 малоселективному полю, то да. Если в составном индексе - другое дело

(25) и что будет в составном индексе? у меня именно такая ситуация?