Индексирование временных таблиц #577311

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

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

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

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

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

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

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

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

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

+ в ВТ

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

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

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

Вообщето есть

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

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

чо?

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

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

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

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

именно составного

40

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

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

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

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

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

Составной индекс делается. Реллакс. T1._IDRRef, T1._Fld8, T1._Fld9, T1._Fld10 FROM _Reference7 T1 WITH(NOLOCK)

"ВЫБРАТЬ

Спасибо.