На бескрайних просторах инета неоднократно встечался со статьей, описывающей причины неоптимальной работы запросов. В данной статье присутствует такая фраза: "В качестве индексных полей следует указать все поля, которые используются в условии соединения". Воспользовавшись данной рекомендацией и получил неожиданный результат: итоговое время выполнения пакета запросов после добавления индексов увеличилось. Где-то в 1,5 раза. Естественно, индексы пихал не во все подряд временные таблицы, а лишь в те, которые заведомо будут весьма большими. Хотелось бы узнать у гуру оптимизации - в каких случая всё-таки следует производить индексацию конкретного поля, и для каких полей индексация будет заведома бессысленна? В общих чертах механизм работы индексов представляю, однако тыканье носом в теорию поощряется.

Учти... Чем больше индексов, тем медленнее вставка. И создание больших индексов - тоже время...

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

(2) если вообще поле уникально все авно работает быстрее, ибо по индексу таки сортируется

Вот и БРАТ на Мисте появился.
Смахнул скупую слезу. :*(

Растет молодежь.

(3) во временной таблице то? ктож ее проиндексирует

А ещё такой момент. При создании индекса по нескольким полям для временной таблицы, как понимаю, - создается составной индекс. Соответственно будет иметь значение - в каком порядке идут поля. В этом случае как будет оптимальней - наверх помещать поля с большим количеством возможных значений, или наоборот?

(6) порядок в составном индексе определяется его использованием

(7) в 1с нет составных индексов

(8)+ в ВТ

(5) ты не поверишь, но 1с это таки умеет

Что мешает проиндексировать временные таблицы ?

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

P.S. правда может получиться, что неправильный в данном случае был выбран индекс.

(9) Вообщето есть v8: Подзапросы с Выбрать Первые

(13) Единственно по убыванию нельзя сортировать, для чисел поле приходиться вводить с обратным знаком

(7) А можно по-подробней?

(14) чо?

(16) На SQL ты можешь задать в составном индексе сортировку по убыванию, в 1С нет

(17) а, я понял твою мысль.

(13) ткни в номер поста, чтоли, а то не вижу создание индекса из профайлера что-то

(17) А может и путаю, но чегото не нашел "Убыв", и не экспереентировал

(19) именно составного

(19) 40

(22) гед там индексирование временных таблиц?

(0) индексировать надо только те поля на которые далее будут накладываться условия, либо по ним будут происходить соединения таблиц.

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

(23)
ПОМЕСТИТЬ РеализацияТоваровУслугТовары
ИЗ
   Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
ГДЕ

  РеализацияТоваровУслугТовары.Ссылка.Дата МЕЖДУ ДАТАВРЕМЯ(2011, 1, 1) И ДАТАВРЕМЯ(2011, 8, 16)
ИНДЕКСИРОВАТЬ ПО
   Ссылка,
   Сумма,
   Количество
;

(25) где это в терминах SQL, чтобы говорить о том, что индексы составные, а не отдельные?

(26) А почему должно быть иначе.Возьми профайлер и проверь. У меня таким образом формируются  таблицы с десятками миллионов записей. Если бы индексы были не составными, то на их создание уходило гораздо больше времени чем сейчас около минуту.

Составной индекс делается.
Реллакс.

create index [TMPIND_0] on [#tt1] (_Q_000_F_001, _Q_000_F_002, _Q_000_F_003)

INSERT INTO #tt1 (_Q_000_F_000RRef, _Q_000_F_001, _Q_000_F_002, _Q_000_F_003) SELECT
T1._IDRRef,
T1._Fld8,
T1._Fld9,
T1._Fld10
FROM _Reference7 T1 WITH(NOLOCK)

"ВЫБРАТЬ
|    Справочник1.Ссылка,
|    Справочник1.Реквизит1 КАК Реквизит1,
|    Справочник1.Реквизит2 КАК Реквизит2,
|    Справочник1.Реквизит3 КАК Реквизит3
|ПОМЕСТИТЬ Временная
|ИЗ
|    Справочник.Справочник1 КАК Справочник1
|
|ИНДЕКСИРОВАТЬ ПО
|    Реквизит1,
|    Реквизит2,
|    Реквизит3";

(29) Спасибо.