запрос  стал тормозить   нашел что долго работает соединение с самописным регистром накопления по заказу покупателя.  в запросе  все ВТ проиндексровал  время сократилось на 30%  теперь тормозит  именно соедиение с таблицей РН.  если я проиндексирую Заказы покупателей в этом регистре  думаю  что производительность еще в плюс пойдет. но таблица 12 миллионов записей  более 3 гигов.  как отразится это на  размерах индексов  и времени регламентных процедур?

(0) Индексы жрут место, это очевидно. Иногда больше чем сами данные.

отразится.
Считай - +20% от размера таблицы.
Соответственно перестройка индекса. И затраты на запись

ну  база  200 гиг  20% от 3,5  фигня :-)   волновали именно затарты на запись   и перестройку  во что выльются.   лана поставлю индекс проверю прирост  запроса в отчете.  если  он того не стоит уберу.

размер данные: индексы  
олтп - 1:1
олап   1:10

индексы могут и поболее талицы быть, причем гораздо

(0)
Найди самое селективное измерение и его только индексируй
Например это ЗаказПокупателя
А кучу индексов делать смысла нет - скорее всего более одного не используется

Вообще запрос надо смотреть

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

(7)
Ну как минимум по умолчанию строится индекс по набору измерений в порядке их расположения в регистре

Если необходим индекс ЗаказПокупателя и он не первый - конечно индексировать(очень сильная селективность)
Если Организация - лучше нет(селективность слабая)

(7) у тебя скорее всего запрос кривой

ЗаказПокупателя  он третий -  поставлю.

(9) тормозит именно внутреннее соедиенение  двух таблиц  по одному полю по ЗаказПокупателя   просто вырос РН   как можно прямее соединить две таблицы  внутренним  по одному полю я ХЗ

(11)
Соединение тормозить не может(практически, теоретически можно забац соединение типа с условием >=  )
Тормозит извлечение данных

ПРисоединюсь к (9) - запрос кривой

(10)
А в запросе точно используется отбор по Заказу покупателя ?

я пришел к выводу  что тут  

ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.СтоимостьПродажиМатериалов КАК СтоимостьПродажиМатериалов
 ПО ВТ_СписокЗаказов.ЗаказПокупателя = СтоимостьПродажиМатериалов.ЗаказПокупателя

отбора по заказу покупателя нет. именно соединение

лана ее пошаманю перед тем как индексирвоать.

ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.СтоимостьПродажиМатериалов(МыПараметрыВставьНасЗдесьПожалуйста)

Ее мое это не виртуальная !

Убери это соединение нафиг - оно если только требуется реквизиты из регистра, все остальное есть в ВТ

(18)  не понял если честно, нашел там вложенный. вынесу в ВТ   избавясь от ВЗ.

(19)
В смысле все данные есть в ВТ (кроме реквизитов, которые почти никогда не нужны)
Поэтому соединение(которое тормозит) использовать не обязательно
Можно ВТ сохранить во временную таблицу, проиндексировать, потом соединиться с этой табл

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

(20) от соединения не избавится.  вот про это я и веду. соедиенение  идет по заказу покупателя  в РН  оно третьим реквизитом и не индексировано.   вот я и хочу ВТ проиндексировать в запросе  а РН  в конфигураторе ессно

(21)  тут   у меня со знаниями вообще плохо  :-( все что я понял что речь идёт о плане запроса и все :-(

(22) РН нельзя по периоду ограничить?

(0) >Насколько сильно влияют индексы на размер БД
А интуитивно прикинуть можно? Что такое индекс вообще по сути???

соединяй не только по заказу но и по первым 2м узмерениям. наверняка это организация, договор

(25) индекс - это доп таблица с отсортированными данными

>Что такое индекс вообще по сути???

сбалансированное дерево. Стало сильно легче?

(26) Некластерный индекс по измерениям?

РН можно ограничить по периоду? Автор, че там с логикой запроса?

(26)+100

(27) Так. Следующий вопрос: насколько размер таблицы индекса будет сравним с размером исходной таблицы? Каково количество таких таблиц???

Вот, исходя из этого можно делать выводы, насколько % он увеличит объемы БД.

>Вот, исходя из этого можно делать выводы, насколько % он увеличит объемы БД.

и что это тебе дает? проблема скорее в кривой выборке а не в объеме

я так понимаю там в соединение используется временная таблица. Попробуй проиндексировать ее по полю условия соединения. Если с обеих сторорн у соединяемых таблиц будет индекс то соединения пройдет в разы быстрее.

(26) номенклатура и характеристика номенклатуры

(34) все с этого и началось  ВТ я могу проиндексировать в запросе  а сам РН не приндесирвоан по этому полю  и ни по какому не проиндесирвоан.

(36)
Их можно добавить в соединение ?

к (35)

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

+(39)  да наверно так и сделаю.   данных за последние  300 дней всегда хватит.  а браться будет  на текущий момент чуть больше трети таблицы.   заменю физическую таблицу РН на виртуальную оборотную.

а вопрос  что будет быстрее :
1. взять оборотную с параметрами по периоду. мне хватит 180 дней  по самое не балуйся.  ничего не индексируя в конфигураторе
2. прочитать физическую таблицы с ограничением по периоду через ГДЕ создав проиндексированную в запросе ВТ с оборотами по периоду

и соединяться либо с оборотной либо с ВТ проиндексирвоанной

(7) (36) Как тебе удалось такой регистр сделать? Это не 1С, тебя обманули.

(35)
Если в ВТ есть номенклатура и характеристика номенклатуры
соединяйся
Если нет - соединение с табличной частью - получаешь номенклатура и характеристика номенклатуры
потом соединение с регистром по
номенклатура, характеристика номенклатуры, заказ покупателя

и никакие доп индексы не нужны

(43) Откуда уверенность, что измерения идут в такой последовательности?

см (35) автор сообщил

(45) Ясно

Не поможет. У него же запрос идет к основной таблице регистра накопления (таблице движений). А у соновной таблицы по умолчанию есть только индексы

Период + Регистратор + НомерСтроки
Регистратор + номерСтроки.

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

Ну и для таблицы итогов по умолчанию индекс

Период + Измерение1 + Измерение2 + ...

Кто подпустил к базе в 200г человека задающего такие вопросы?

(47)+ это к (26) и (43).
(41) В первом варианте есть вероятность неадекватного плана запроса, правда величину этой вероятности не берусь оценить.
Второй вариант в этом плане надежнее, но на ваших объемах могут быть большие накладные расходы на создание временной таблицы и ее индексации.

(47) Про Период то мы и забыли.

С учетом (41) , то есть ограничения периода, соединяй как в (26) или (43) добавь в условия соеднения еще и период, правда там условие получится через ">", так что тоже не айс получится.

(51) Почему?

Больше-Меньше для Индекса -норм!

(47)
Да.
Тогда можно либо проиндексировать измерение все таки
Либо ограничить период получением из его виртуальной таблицы(? откуда он ее берет) дибо снизу датой мин ЗаявкаПокупателя

Ну и сам запрос к таблице оборотов, а не к физической

Вообще период жестко обычно в самом отчете задается - шо за запрос ?

В (41) он уже решил ограничивать период выборки из таблицы движений.

Сорри   извините. я  промахнулся регистром  ЗаказПокупателя  стоит первым в измерениях!!!  получается  индексировать его не нужно.

См выше написали
Там только индексы ByPeriod
и ByRecorder(через регистратор)
Таблица оборотов  отсутствует (сейчас в отладчик глянул) для рег остатков.
так что надо.


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

(58)  это не рег остатков  я выше писал это таблица оборотов  и виртуальная таблица  оборотво присутствует.   Помнится ранее на более страых платформах быстрее было сваять свою ВТ  чем пользовать таблицу оборотв.  ща засерю что лучше.

для начала  я пошел как делал раньше.  прочитал физическую  таблицу в ВТ ограничил через ГДЕ период между датами текущая и текущая минус 90 дней. создал индекс по заказ покупателя  и в соедиенние  пихал уже проиндексированную ВТ.   запрос отработал вдвое быстрее.   Сейчас замерю с  обрезанием виртуальной таблицы оборотов параметрами

Ну так вместо физической сразу цепляйся к вирт табл оборотов.
В параметрах таблицы нужно ограничить период и Измерение ЗаказПокупателя, чтобы использовать индекс
ByDims = Period+Измерение1+Измерение2+ ....

Если вдруг не хватит данных из Оборотов, потом соединяйся с основной по регистратору/периоду

(57) Сколько ни пытался экспериментировать с индексированием в РН, большого эффекта не получил.

(61) А не пробовал скулем составной индекс создавать? :-)

И так.

1.  соединение с физической таблицей оборотного регистра  73сек

2. перед соединением прочитал виртуальную таблицу оборотов в ВТ обрезал период параметрами и проиндексировал ВТ
52 сек  по полю соединения

3. перед соединением прочитал физическую таблицу оборотного РН в ВТ обрезал период в секции ГДЕ методом между и проиндексировал ВТ по полю соединения
27 сек

я у Гилева когда то читал  что виртуальные таблицы оборотов  не всегда оптимальны  и часто проще самому  создать нужную на основании физической и потом ее юзать

Выложи что наваял - не стесняйся)

(65)  это один из моментов  в запросе  сам запрос большой.  могу и выложить чего мне бояться :) просто смысл то какой.  я точно определил что проблема именно в запросе  где  идет соединение  с РН  и выборка полей из него

ща выдеру

вот  кусок который  отрабатывает  70 секунд :


////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   ВЗ_СтоимостьПродажиМатериалов.Продукция,
   ВЗ_СтоимостьПродажиМатериалов.ХарактеристикаПродукции,
   ВЗ_СтоимостьПродажиМатериалов.Номенклатура,
   ВЗ_СтоимостьПродажиМатериалов.ОсновнаяПродукция,
   ВЗ_СтоимостьПродажиМатериалов.ХарактеристикаОсновнойПродукции,
   ВЫБОР
       КОГДА НеСтандартныеСтекла.Номенклатура ЕСТЬ NULL
           ТОГДА ЛОЖЬ
       ИНАЧЕ ИСТИНА
   КОНЕЦ КАК НеСтандартноеСтекло
ПОМЕСТИТЬ ВТ_СтоимостьПродажиМатериалов
ИЗ
   (ВЫБРАТЬ
       БВ_СтоимостьПродажиМатериалов.Продукция КАК Продукция,
       БВ_СтоимостьПродажиМатериалов.ХарактеристикаПродукции КАК ХарактеристикаПродукции,
       БВ_СтоимостьПродажиМатериалов.Номенклатура КАК Номенклатура,
       БВ_СтоимостьПродажиМатериалов.ОсновнаяПродукция КАК ОсновнаяПродукция,
       БВ_СтоимостьПродажиМатериалов.ХарактеристикаОсновнойПродукции КАК ХарактеристикаОсновнойПродукции
   ИЗ
       (ВЫБРАТЬ
           ТаблицаПродукции.ЗаказПокупателя КАК ЗаказПокупателя
       ИЗ
           ТаблицаПродукции КАК ТаблицаПродукции
       
       СГРУППИРОВАТЬ ПО
           ТаблицаПродукции.ЗаказПокупателя) КАК ВЗ_СписокЗаказов
           ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.БВ_СтоимостьПродажиМатериалов КАК БВ_СтоимостьПродажиМатериалов
           ПО ВЗ_СписокЗаказов.ЗаказПокупателя = БВ_СтоимостьПродажиМатериалов.ЗаказПокупателя) КАК ВЗ_СтоимостьПродажиМатериалов
       ЛЕВОЕ СОЕДИНЕНИЕ НеСтандартныеСтекла КАК НеСтандартныеСтекла
       ПО ВЗ_СтоимостьПродажиМатериалов.Номенклатура = НеСтандартныеСтекла.Номенклатура
           И (ВЗ_СтоимостьПродажиМатериалов.Продукция.ВидНоменклатуры = &Стеклопакет)
;

////////////////////////////////////////////////////////////////////////////////

я в первую очередь избавился от двух вложенных ВЗ

вот к чему я привел исходный запрос и получил около 25-28 секунд


////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   ТаблицаПродукции.ЗаказПокупателя КАК ЗаказПокупателя
ПОМЕСТИТЬ ВТ_СписокЗаказов
ИЗ
   ТаблицаПродукции КАК ТаблицаПродукции

СГРУППИРОВАТЬ ПО
   ТаблицаПродукции.ЗаказПокупателя
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   БВ_СтоимостьПродажиМатериалов.ЗаказПокупателя КАК ЗаказПокупателя,
   БВ_СтоимостьПродажиМатериалов.Продукция,
   БВ_СтоимостьПродажиМатериалов.ХарактеристикаПродукции,
   БВ_СтоимостьПродажиМатериалов.Номенклатура,
   БВ_СтоимостьПродажиМатериалов.ОсновнаяПродукция,
   БВ_СтоимостьПродажиМатериалов.ХарактеристикаОсновнойПродукции
ПОМЕСТИТЬ ВТ_РН_СтоиомстьМатериалов
ИЗ
   РегистрНакопления.БВ_СтоимостьПродажиМатериалов КАК БВ_СтоимостьПродажиМатериалов
ГДЕ
   БВ_СтоимостьПродажиМатериалов.Период МЕЖДУ &ДатаНачПериода И &ДатаКонПериода

ИНДЕКСИРОВАТЬ ПО
   ЗаказПокупателя
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   ВТ_РН_СтоиомстьМатериалов.Продукция КАК Продукция,
   ВТ_РН_СтоиомстьМатериалов.ХарактеристикаПродукции КАК ХарактеристикаПродукции,
   ВТ_РН_СтоиомстьМатериалов.Номенклатура КАК Номенклатура,
   ВТ_РН_СтоиомстьМатериалов.ОсновнаяПродукция КАК ОсновнаяПродукция,
   ВТ_РН_СтоиомстьМатериалов.ХарактеристикаОсновнойПродукции КАК ХарактеристикаОсновнойПродукции
ПОМЕСТИТЬ ВТ_СтоимостьПродажиМатериаловБывшаяВЗ
ИЗ
   ВТ_СписокЗаказов КАК ВТ_СписокЗаказов
       ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_РН_СтоиомстьМатериалов КАК ВТ_РН_СтоиомстьМатериалов
       ПО ВТ_СписокЗаказов.ЗаказПокупателя = ВТ_РН_СтоиомстьМатериалов.ЗаказПокупателя
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
   ВТ_СтоимостьПродажиМатериаловБывшаяВЗ.Продукция,
   ВТ_СтоимостьПродажиМатериаловБывшаяВЗ.ХарактеристикаПродукции,
   ВТ_СтоимостьПродажиМатериаловБывшаяВЗ.Номенклатура,
   ВТ_СтоимостьПродажиМатериаловБывшаяВЗ.ОсновнаяПродукция,
   ВТ_СтоимостьПродажиМатериаловБывшаяВЗ.ХарактеристикаОсновнойПродукции,
   ВЫБОР
       КОГДА НеСтандартныеСтекла.Номенклатура ЕСТЬ NULL
           ТОГДА ЛОЖЬ
       ИНАЧЕ ИСТИНА
   КОНЕЦ КАК НеСтандартноеСтекло
ПОМЕСТИТЬ ВТ_СтоимостьПродажиМатериалов
ИЗ
   ВТ_СтоимостьПродажиМатериаловБывшаяВЗ КАК ВТ_СтоимостьПродажиМатериаловБывшаяВЗ
       ЛЕВОЕ СОЕДИНЕНИЕ НеСтандартныеСтекла КАК НеСтандартныеСтекла
       ПО ВТ_СтоимостьПродажиМатериаловБывшаяВЗ.Номенклатура = НеСтандартныеСтекла.Номенклатура
           И (ВТ_СтоимостьПродажиМатериаловБывшаяВЗ.Продукция.ВидНоменклатуры = &Стеклопакет)
;

////////////////////////////////////////////////////////////////////////////////

(65)  Ты так  активно болел за результат что тебе не откажу :-)

(70) Если убрать "ИНДЕКСИРОВАТЬ ПО", то насколько изменится результат?

2 запрос заменить на

ВЫБРАТЬ
   БВ_СтоимостьПродажиМатериалов.ЗаказПокупателя КАК ЗаказПокупателя,
   БВ_СтоимостьПродажиМатериалов.Продукция,
   БВ_СтоимостьПродажиМатериалов.ХарактеристикаПродукции,
   БВ_СтоимостьПродажиМатериалов.Номенклатура,
   БВ_СтоимостьПродажиМатериалов.ОсновнаяПродукция,
   БВ_СтоимостьПродажиМатериалов.ХарактеристикаОсновнойПродукции
ПОМЕСТИТЬ ВТ_РН_СтоиомстьМатериалов
ИЗ
   РегистрНакопления.БВ_СтоимостьПродажиМатериалов.Обороты(&ДатаНачПериода,&ДатаКонПериода,,ЗаказПокупателя в (ВЫБРАТЬ ЗаказПокупателя ИЗ ВТ_СписокЗаказов)) КАК БВ_СтоимостьПродажиМатериалов


ИНДЕКСИРОВАТЬ ПО
   ЗаказПокупателя
;

(72)  пять сек замерю. а в какую сторону  ожидаете изменения ? :)

и 3 запрос соответственно лишний

(72) с Индексировать ПО  три замера 23,20,22  секунды

// Индексировать по

ШАЙТАН   3.1   3.4   3.02


ща повторю еще раз   с  и без

ИНДЕКСИРОВАТЬ ПО    19.7   22.5   20.4
//ИНДЕКСИРОВАТЬ ПО   3.3   3.8   6.1

супер.   т.е. как я понимаю  ГДЕ  работало после индексирования т.е. индексировалась вся физ таблица

(77) Т.е. без "ИНДЕКСИРОВАТЬ ПО" быстрее?
Думаю, у тебя просто кэш СУБД так отработал.

ИМХО, смысл в "ИНДЕКСИРОВАТЬ ПО" возникает очень редко.

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

галки индексировать в измерении регистра не ставил там везде отключена. вкладывал в слова то что не знаю  в какой момент происходит индексация  до обрезки условием "ГДЕ" по периоду или после.  потому что до обрезки по периоду  там  2,5 года  а после 3 месяца.

без ИНДЕКСИРОВАТЬ ПО   быстрее в разы

(73) (75)  обязательно проверю и это. результат через полчасика отпишу

(80) Не должно быть такой разницы. Выполни запросы в разном порядке и несколько раз.

я думаю   что  внутреннее   будет работать быстрее чем такой параметр у оборотной

(82) ну я выполнял  но не в разном порядке а подряд 3 раза  с индексированием,  три без  , три с , три без

(63) Скорее всего в виртуальной таблице идет объединение таблицы итогов (если включены итоги) с движениями по неполному периоду плюс Group by.
Апо физической таблице тупо по индексу выгребли строки, ну разве что запись временной еще (это и варианте в виртуальной есть).

ща проведу тест в пермешку
начну с индексом и чередовать с тем что без :

20.4  4.7  19.5  3.1  ну короче надоело :-)

То ptiz   еще раз респект.   не знаю через сколько времени я попробовал бы формировать без индексирования  ВТ

(0) в кубах данных когда индексируется и копятся итоги по индексам, есть даже такое понятие "взрыв данных" - когда база становится нерабочей. так что индексы можно наворочить так что.... :)

И таки наверное Group by по таблице движений по не индексированным полям и заутпил прилично.
Можено проэкспериментировать.

ВЫБРАТЬ Различные
   БВ_СтоимостьПродажиМатериалов.ЗаказПокупателя КАК ЗаказПокупателя,
   БВ_СтоимостьПродажиМатериалов.Продукция,
   БВ_СтоимостьПродажиМатериалов.ХарактеристикаПродукции,
   БВ_СтоимостьПродажиМатериалов.Номенклатура,
   БВ_СтоимостьПродажиМатериалов.ОсновнаяПродукция,
   БВ_СтоимостьПродажиМатериалов.ХарактеристикаОсновнойПродукции
ПОМЕСТИТЬ ВТ_РН_СтоиомстьМатериалов
ИЗ
   РегистрНакопления.БВ_СтоимостьПродажиМатериалов КАК БВ_СтоимостьПродажиМатериалов
ГДЕ
   БВ_СтоимостьПродажиМатериалов.Период МЕЖДУ &ДатаНачПериода И &ДатаКонПериода

по идее должно быть меделннее.

(89)+ Заутпил, имел ввиду при использовании виртуальной таблицы оборотов.

на текущий момент  отслежу стабильность.  и если из рамок  текущих замеров не выйдет  то результат устраивает.