Открыл тут для себя Америку, хотелось бы услышать мнение 330-ников.
Оказывается сабж нислабо влияет на производительность. Типа именно в таком порядке строятся индексы, в каком указаны измерения в пофигураторе.
К примеру индекс "Склад1,Товар1" быстрее найдётся при поиске по "Склад1", чем при поиске по "Товар1".

http://www.forum.mista.ru/topic.php?id=694500
http://www.gilev.ru/index/

да, ты действительно омеригу открыл ;)

(1) это только для регистров Накопления, или для всех?

(2) дык ноги вообще из скуля растут, 1с - посредник.

ктстати, интересно, как с этим дело обстоит в файловой версии, не проверял

(3) ан нет! Виртуальные таблицы всё равно индексируются:

GROOVY: Данные по которым строятся вирт таблицы и так индексируются, а к реальным движениям вроде как не модно обращаться, нафига их индексировать?
...
GROOVY: Для целей расчета показателей виртуальных таблиц значения измерений однозначно проиндексированы.

А может это просто потому что складов не больше десятка, а товаров несколько тысяч? ) Вроде бы индексы друг на друга не завязанны, и какая разница в каком они порядке...

сабж осуждаю. Мне казалось это только для 7ки было актуально.

(8)
Оборотный регистр. Контрагентов 1000, договоров 10000, товаров 100000.
Какой порядок измерений?

Регистр остатков. Складов 10, товаров 1000, серий 10000
Какой порядок измерений?

(7) какие джойны, если регистр один? Ты предлагаешь делать два позапроса к одному регистру?

(9) и что? тема сисек не раскрыта. или мы обсуждаем вопрос производительности в некой теоретической базе?

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

(7) я себе индекс представлял как текстовое поле, отсортированное по алфавиту.
Что то вроде:

"СсылкаНаОбьект1, СсылкаНаОбьект2"
"СсылкаНаОбьект1, СсылкаНаОбьект3"
"СсылкаНаОбьект1, СсылкаНаОбьект4"
"СсылкаНаОбьект5, СсылкаНаОбьект2"
"СсылкаНаОбьект5, СсылкаНаОбьект3"
"СсылкаНаОбьект5, СсылкаНаОбьект4"

Естественно отбор по первому измерению: "СсылкаНаОбьект5%" отработает быстрее чем по второму: "%СсылкаНаОбьект2"

(12) это если по второму измерению нет индекса. а если есть то пофиг на порядок.
и да, мы же говорим про "таблицу движений"

(13) для простоты считаем что по обоим измерениям в конфигураторе стоит "не индексировать" см.(5)

(14) в целом да, но есть "нюансы".

в таблице остатков будет индекс:
Период + Измерение1 + ... + ИзмерениеN (Кластерный)+ Splitter и работать он будет как ты хочешь в (12)

БухиТог Типа именно в таком порядке строятся индексы

ну а это не совсем так.
индекс только один - кластерный

Фух, дочитал только до середины статьи. Ушел думать спать.
http://www.sql.ru/articles/mssql/03013101indexes.shtml

sf (9) и что? тема сисек не раскрыта. или мы обсуждаем вопрос производительности в некой теоретической базе?
если вы намекаете, что должно быть именно в вами указанном порядке - то это не обязательно. Все зависит от задачи.

Ну вроде гуру пишут, что порядок = тяжести, т.е:
1. Товар, Договор, Контрагент
2. Серия, Товар, Склад

Почему в типовых не так?

(18) да скулю вообще на порядок насрать. есть индекс - отбор быстрее. нет индекса - идет скан.
если решать задачу "универсально", то порядок и вправду должен быть от частоты использования.
т.е. если мы просим скул выдать нам "склад-номенклатура-серия" и чаще смотрим остатки с фильтром по "складу", потом иногда смотрим по склад+номенклатура, и еще реже "склад-номенклатура-серия", то надо именно в порядке
склад-номенклатура-серия. - т.к. кластерный будет использоваться во всех трех популярных вариантах и данные сразу упорядочены как нам надо.
но если мы будем смотреть отдельно остатки номенклатуры по всем складам и у нас по номенклатуре нет отдельно "индескировать", то будет фул-скан.

(10) Регистр один, таблиц-то две, индексов как минимум столько же...

(20) да че мелочиться-то. как минимум три индекса.

Братцы, что то вас не туда понесло!
Я так понимаю что речь идет про композитный индекс, ключ состоит из нескольких полей. И порядок следования полей в этом ключе соответствует порядку измерений.
Цитирую статью из (17):

16.3. Композитный индекс

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

Например, если создается индекс по полям Field1, Field2, то он может быть применен только в запросе где в критериях используются оба этих поля. Так же этот индекс будет полезен для условий, построенных для одного Field1. Для одного Field2 этот индекс не может быть применен.

Если в дополнении к индексу по полям Field1, Field2 добавить индекс по полям Field2, Field1, то SQL Server при построении плана запроса будет анализировать какой из них более селективен в применении к ограничениям на условия запроса. Последний момент в построении композитного индекса по полям Field1, Field2 – он не равен сумме индексов по указанным полям. В случае когда в запросе могут быть использованы оба поля как критерий поиска при раздельных индексах по полям будет построено пересечение по индексам, что медленнее чем выборка из компаундного индекса.

Т.е. всё как я и писал в (12)

(23) А есть он там? В стандартных таблицах вроде как такие были, ну типа документов там. В регистрах чет не припомню таких. Регистр накоплений это вообще говоря две таблицы, а не одна и выборка идет более замысловато. Сначала по итогам на начало месяца данные ищем, потом по движениям к ним плюсуем. Не так-то просто подобное проиндексировать по нескольким полям...

sf да скулю вообще на порядок насрать

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

andrewks очень важен в скуле

готов обсудить. чем?

На самом деле просто упростили до товара и склада, а в реальном-то регистре тех измерений 15 штук может быть. Станет ли он составной мутить из 15 измерений? Да по такому будет дольше искать, чем простым перебором...

Дядя Вася составной

andrewks составном индексе

о. гуру, откройте секрет как составной индекс намутить в 1Ске

(29) Ну вообще-то они там есть, но по таблицам с известной смысловой нагрузкой. Заранее известной. У тех же документов например есть дата и номер и по ним обоим отсортировать логично, 1С-ка про это в курсе. А какой смысл в твоих измерениях регистра она понятия не имеет.

(30) аккуратней, это же не ветка про авиацию, где проверить сложно как эксперты работают [smile=:D]

повторю вопрос: "как намутить в 1С составной индекс" ?
про стандартные я не спрашиваю

Дядя Вася например есть дата и номер и по ним обоим отсортировать логично

кстати, зачет. расскажи как

(29) а разве в сабже не об этом говорится?

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

(27) скоростью выполнения запросов, не?

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

Дядя Вася вряд ли он есть...

ты цыган что ль? или потомственная гадалка?
вот это:

sf Период + Измерение1 + ... + ИзмерениеN (Кластерный)+ Splitter

а вот этого нет:

Дядя Вася У тех же документов например есть дата и номер и по ним обоим отсортировать логично

если есть, расскажи как. ну мне реально интересно

sf а вот этого нет:
Дядя Вася У тех же документов например есть дата и номер и по ним обоим отсортировать логично

Он там изначально есть, даже в семерке. Реализованно на уровне движка :) Ручками ты такой понятно не сделаешь.

(33) чорт, чё-то я протупил. я про составные индексы подумал

andrewks скоростью выполнения запросов, не?

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

sf или мы про разное говорим?

во-во. я про составной имел в виду

Дядя Вася Он там изначально есть

Дядя Вася Реализованно на уровне движка

мы же про 8ку говорим?
я вижу: индексы
Дата + Ссылка
Номер + Ссылка

дата+номер не вижу :(

sf если ты ставишь отбор товар-серия-склад. оно будет медленнее работать?

для ответа на этот вопрос нужно видеть, в какой скуль-запрос 1сина транслирует, ибо порядок может поменяться оптимизатором 1с, например

(41) В журналах посмотри, нешто отменили... Нелогично.

(44) рассмотрим задачу когда нам остатки из итогов надо получить, они рассчитаны и не надо ничего "считать"

(45) Сферический конь в вакууме )

(43) имхается мне, что и не было никогда (в 8ке)
нафиг он нужен.
в журнале тоже нет, да ты и про документы писал.
хотя да, критерии отбора и графы журналов - неявно добавят индекс. но не к номеру и не составной.

(47) В семерке были, в общем.
(48) Потому что искусственная задача к реальной жизни имеющая мало отношения. Даже если ты будешь писать запрос только к таблице итогов, тебе скорее все равно считать придется. Есть у тебя там итоги по каждому складу-товару-серии, а пользователю не интересно в разрезе серий, он хочет например посмотреть сколько нужного товара всего на основном складе, или вообще на всех складах.

(49) я хотел было слово оптимизатор в кавычки поставить, но не стал )

Дядя Вася искусственная задача к реальной жизни имеющая мало отношения.

не надо ничего придумывать, давай сначала:
Регистр накопления остатки "ТоварыНаСкладах". Измерения: Склад, Номенклатура,Серия. Ресурсы: Количество
Запрос:
Выбрать Остатки.Количество
из РН.ТоварыНаСкладах.Остатки КАК Остатки
ГДЕ
Остатки.Номеклатура = &Номеклатура И Остатки.Серия = &Серия И Остатки.Склад = &Склад

как будет себя вести скуль?

и есть ли разница в случаях когда измерения в конфигураторе будут в порядке: "Номенклатура,Серия,Склад"

или будет ли по-другому (быстрее?) работать запрос:
Выбрать Остатки.Количество
из РН.ТоварыНаСкладах.Остатки КАК Остатки
ГДЕ
Остатки.Склад = &Склад И Остатки.Номеклатура = &Номеклатура И Остатки.Серия = &Серия

?

(52) Ну это само собой, просто сколько он записей перебирет чтобы получить итог который тебе нужен, а не в том разрезе в котором они в таблице хранятся? С применением составного индекса понятно переберет меньше, но для этого он должен быть продуман. Одинэска не в курсе смысловой нагрузки измерений. На момент создания регистра она не знает, что у тебя будет 10 складов, и 10000 товаров, а не наоборот. Названия измерений ей не говорят ни о чем. На самом деле это может быть не товар и склад, а что-то еще, и по 1000 каждого. Тогда в таком индексе вообще нет смысла, в каком порядке его не строй, количество итераций такое же будет. Потому сама она его грамотно построить не в состоянии, а в макроязыке это сделать возможности не предусмотрели.

(55) я так понял, ты сливаешься? [smile=:D]

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

кто победил?

Дядя Вася даже если он и составной

т.е. ты знаешь способ как сделать в 1С составной индекс?

(60) Смотря в какой 1С... В семерке с прямыми и не то можно сделать. )

(61) ты или Кэп или некомпетентный как ...
причем здесь прямые запросы?
я тоже могу зайти в скуль и ручками создать там составной индекс. мы же говорим про средства 1С?

(62) А вам шашечки или ехать? Создать-то ты его в скуле можешь, только будет ли он использоваться интересный вопрос. С прямыми в семерке будет, потому как непосредственно со скулем и работаешь. А восьмерка из макроязыка в скулевские свои запросы транслирует как умеет, и про твой индекс она не в курсе...

(63)
ты это.... завязывай с алкоголем. причем здесь трансляция языка 1Ской и индекс?

Дядя Вася Станет ли он составной мутить из 15 измерений?

я до сих пор не могу понять, про какую реальность ты пишешь? мы тут в сабже вроде не клюшки обсуждаем.

хотя стоп. расскажи как использовать сделать и использовать составной индекс в 7ке?

(64) Ну хранимки-то делал, чего бы и с индексом не извернуться. Понятно что это уже не просто семерка, но возможность-то есть.

так что в итоге? зачем порядок нужен в измерениях?
я проверил сейчас: в любом порядке ставь условия - будет использоваться кластерный индекс

Провел такой эксперимент:

1. Определяем структуру таблиц для регистра "ПартииНаСкладе" с помощью метода "ПолучитьСтруктуруХраненияБазыДанных"

2. Смотрим структуру индексов ДО установки в измерениях галок Индексировать!

И самое интересное!!

Т.е. в таблице Итогов в составе кластерного индекса присутсвуют ВСЕ измерения. Несмотря на осутствие галок "Индексировать" в 1С
Видимо про это писал Груви!

3. Измерение"Склад" делаем числовым чтобы отличить его от остальных:

4. Меняем порядок измерений:

Что и требовалось доказать!!!

З.Ы.: Позже покажу что происходит по галке "Индексировать". Сейчас времени нет. Но там ничего интересного, просто добавляется еще один некластеризованный индекс, отделный индекс по каждому измерению, по которому стоит галка.

БухиТог Т.е. в таблице Итогов в составе кластерного индекса присутсвуют ВСЕ измерения.

ну, в принципе, это логично

(68) и их порядок в составном индексе меняется при изменении порядка измерений в Конфигураторе!!!

(69) не составном, а кластеризованном. а то опять путаемся в терминах

А вот так меняется состав колонк.

Меянем порядок измерений:

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

(72)(73) а еще разные переводы в разных редакциях/версиях MS SQL. Имхо, это эхо холодной войны.

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

(73) Как не составной?! Полей же несколько!

хм... ну, да, в таблице итогов

(76) да можно хоть сколько спорить про термины в русских статьях.
открой скуль и найди там слово составной.

(80) под термином "составной индекс" подразумевается индекс с ключом строки, состоящим из более чем одного столбца/поля

Минуточку, а как это будет работать в свете (23)? В частности это:

БухиТог Например, если создается индекс по полям Field1, Field2, то он может быть применен только в запросе где в критериях используются оба этих поля. Так же этот индекс будет полезен для условий, построенных для одного Field1. Для одного Field2 этот индекс не может быть применен.

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

(76) давай лучше вернемся к сабжу: почему важен порядок?

Дядя Вася то индекс вообще не используется

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

sf выборка из индекса

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

(85) Ну это можно проще сделать: https://translate.google.com/?hl=ru#ru/en/составной
13 вариантов перевода, composite в том числе.

(86) мне не нужны варианты перевода, мне нужен официальный перевод, т.е. перевод на оф.сайте, ссылку на который я и привёл

(78) так весь мораль моих скриншотов в (67) был что порядок измерений влияет только на индекс таблицы итогов! Он является кластеризованным и композитным (составным).

(89) так вот и получается, что в данном случае порядок не важен нифига

(90) чччорт! Как не важен?!
Обоснуй!

(87) исходное слово там composite.

БухиТог Как не важен?!
Обоснуй!

ты первый начал. почему важен?

повторюсь: я проверил фильтр по любой колонке 1,2,3 - работает по индексу

sf исходное слово там composite

что за исходное слово? я тебе ссылку на вариант перевода на русском языке привёл, там - "составной"

(93) исходное - на английском. я к тому что спор "композитный" или "составной" - ни о чем.

по мне так вообще пофиг составной, несоставной, композитный / некомпозитный.
Кластерный и не кластерный - вот в чем вопрос )
где рекомендации по порядку полей именно для скуля.

sf я к тому что спор "композитный" или "составной" - ни о чем.

дык и я об том же ))

Индексная селективность - отношение числа строк соответствующих конкретному ключевому значению к общему числу строк в индексе. Селективность индекса – это показатель того, сколько строк от общего числа приходится на одно ключевое значение индекса.
Селективность чаще вычисляют в процентах. Чем больше этот процент, тем хуже селективность. Селективность хороша, если мало строк имеют одинаковые ключевые значения.
Индексный доступ к данным имеет смысл при хорошей селективности. Это утверждение верно при равномерном распределении данных. Однако для ситуации с неравномерным распределением данных такой подход не оправдан.

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

(97) ты сейчас нам все шаблоны порвешь.
т.е. лучше:
серия - номенклатура - склад ????

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