Открыл тут для себя Америку, хотелось бы услышать мнение 330-ников.
Оказывается сабж нислабо влияет на производительность. Типа именно в таком порядке строятся индексы, в каком указаны измерения в пофигураторе.
К примеру индекс "Склад1,Товар1" быстрее найдётся при поиске по "Склад1", чем при поиске по "Товар1".
http://www.forum.mista.ru/topic.php?id=694500
http://www.gilev.ru/index/
(33) чорт, чё-то я протупил. я про составные индексы подумал
sf или мы про разное говорим?
во-во. я про составной имел в виду
(47) В семерке были, в общем.
(48) Потому что искусственная задача к реальной жизни имеющая мало отношения. Даже если ты будешь писать запрос только к таблице итогов, тебе скорее все равно считать придется. Есть у тебя там итоги по каждому складу-товару-серии, а пользователю не интересно в разрезе серий, он хочет например посмотреть сколько нужного товара всего на основном складе, или вообще на всех складах.
(49) я хотел было слово оптимизатор в кавычки поставить, но не стал )
Дядя Вася искусственная задача к реальной жизни имеющая мало отношения.
не надо ничего придумывать, давай сначала:
Регистр накопления остатки "ТоварыНаСкладах". Измерения: Склад, Номенклатура,Серия. Ресурсы: Количество
Запрос:
Выбрать Остатки.Количество
из РН.ТоварыНаСкладах.Остатки КАК Остатки
ГДЕ
Остатки.Номеклатура = &Номеклатура И Остатки.Серия = &Серия И Остатки.Склад = &Склад
как будет себя вести скуль?
и есть ли разница в случаях когда измерения в конфигураторе будут в порядке: "Номенклатура,Серия,Склад"
или будет ли по-другому (быстрее?) работать запрос:
Выбрать Остатки.Количество
из РН.ТоварыНаСкладах.Остатки КАК Остатки
ГДЕ
Остатки.Склад = &Склад И Остатки.Номеклатура = &Номеклатура И Остатки.Серия = &Серия
?
(52) Ну это само собой, просто сколько он записей перебирет чтобы получить итог который тебе нужен, а не в том разрезе в котором они в таблице хранятся? С применением составного индекса понятно переберет меньше, но для этого он должен быть продуман. Одинэска не в курсе смысловой нагрузки измерений. На момент создания регистра она не знает, что у тебя будет 10 складов, и 10000 товаров, а не наоборот. Названия измерений ей не говорят ни о чем. На самом деле это может быть не товар и склад, а что-то еще, и по 1000 каждого. Тогда в таком индексе вообще нет смысла, в каком порядке его не строй, количество итераций такое же будет. Потому сама она его грамотно построить не в состоянии, а в макроязыке это сделать возможности не предусмотрели.
(55) я так понял, ты сливаешься? [smile=:D]
да просто спор ни о чем, ты задачу упростил до таблицы итогов, а в реальной жизни такого нет.
(57)+ И собственно что ты доказать хочешь не понимаю. При сортировке Дата-Склад-Номенклатура-Серия отработает быстрее если тебе нужна например номенклатура без учета серии, и медленнее если она нужна без учета склада. Так что идеальных индексов не бывает, даже если он и составной. Разве что несколько замутить, на все случаи жизни, но это уже избыточная инфа. Не столько полезных записей, сколько записей о том как их обходить.
кто победил?
(62) А вам шашечки или ехать? Создать-то ты его в скуле можешь, только будет ли он использоваться интересный вопрос. С прямыми в семерке будет, потому как непосредственно со скулем и работаешь. А восьмерка из макроязыка в скулевские свои запросы транслирует как умеет, и про твой индекс она не в курсе...
(63) 
ты это.... завязывай с алкоголем. причем здесь трансляция языка 1Ской и индекс?
Дядя Вася Станет ли он составной мутить из 15 измерений?
я до сих пор не могу понять, про какую реальность ты пишешь? мы тут в сабже вроде не клюшки обсуждаем.
хотя стоп. расскажи как использовать сделать и использовать составной индекс в 7ке?
(64) Ну хранимки-то делал, чего бы и с индексом не извернуться. Понятно что это уже не просто семерка, но возможность-то есть.
так что в итоге? зачем порядок нужен в измерениях?
я проверил сейчас: в любом порядке ставь условия - будет использоваться кластерный индекс
Провел такой эксперимент:
1. Определяем структуру таблиц для регистра "ПартииНаСкладе" с помощью метода "ПолучитьСтруктуруХраненияБазыДанных"
2. Смотрим структуру индексов ДО установки в измерениях галок Индексировать!
И самое интересное!!
Т.е. в таблице Итогов в составе кластерного индекса присутсвуют ВСЕ измерения. Несмотря на осутствие галок "Индексировать" в 1С
Видимо про это писал Груви!
3. Измерение"Склад" делаем числовым чтобы отличить его от остальных:
4. Меняем порядок измерений:
Что и требовалось доказать!!!
З.Ы.: Позже покажу что происходит по галке "Индексировать". Сейчас времени нет. Но там ничего интересного, просто добавляется еще один некластеризованный индекс, отделный индекс по каждому измерению, по которому стоит галка.
А вот так меняется состав колонк.
Меянем порядок измерений:
БухиТог Точнее не составной, а композитный
оба термина применимы
composite - составной объект m (Компьютерный)
(80) под термином "составной индекс" подразумевается индекс с ключом строки, состоящим из более чем одного столбца/поля
Минуточку, а как это будет работать в свете (23)? В частности это:
БухиТог Например, если создается индекс по полям Field1, Field2, то он может быть применен только в запросе где в критериях используются оба этих поля. Так же этот индекс будет полезен для условий, построенных для одного Field1. Для одного Field2 этот индекс не может быть применен.
Получается что индекс работает только если выбирать по полям в порядке следования, если на первом месте Контрагент, на втором склад, а мне нужно просто по складу, одну сумму, без контрагентов и прочих товаров, то индекс вообще не используется? А на практике покажет мгновенно...
sf открой скуль и найди там слово составной.
в документации фигурирует
http://msdn.microsoft.com/ru-ru/library/ms188783.aspx
(85) Ну это можно проще сделать: https://translate.google.com/?hl=ru#ru/en/составной
13 вариантов перевода, composite в том числе.
+(84) только, если я правильно понимаю, в нашем случае кластеризованный использоваться не будет, а будут по-отдельности использоваться простые индексы, из которых он состоит, так?
(93) исходное - на английском. я к тому что спор "композитный" или "составной" - ни о чем.
по мне так вообще пофиг составной, несоставной, композитный / некомпозитный.
Кластерный и не кластерный - вот в чем вопрос )
где рекомендации по порядку полей именно для скуля.
sf я к тому что спор "композитный" или "составной" - ни о чем.
дык и я об том же ))
Индексная селективность - отношение числа строк соответствующих конкретному ключевому значению к общему числу строк в индексе. Селективность индекса – это показатель того, сколько строк от общего числа приходится на одно ключевое значение индекса.
Селективность чаще вычисляют в процентах. Чем больше этот процент, тем хуже селективность. Селективность хороша, если мало строк имеют одинаковые ключевые значения.
Индексный доступ к данным имеет смысл при хорошей селективности. Это утверждение верно при равномерном распределении данных. Однако для ситуации с неравномерным распределением данных такой подход не оправдан.
Первым измерением лучше делать, то чего будет больше и разнообразнее. Например булевые поля не имеет смысла индексировать.
(101) dell
(104) прошу считать картинку неправильной :(
это с эксперимента с "составным индексом aaaa"
сейчас сделаю другую
(96) где написал? Закеж!
(112) что ты такое говоришь.... там же место для FK, что 1с-ка никогда не делала )
хотя, мечты-мечты
4 запроса (текст запроса выдернул с ТЖ, чтобы точно было то, что 1с-ка передает): 1. условие по всем измерениям; 2,3,4 - условия по очереди по первому, второму, третьему измерению.
вывод - индекс используется всегда....
вопрос открыт "а влияет ли порядок"
sf вывод - индекс используется всегда....
и то хорошо
хотя он всё равно ругается на некоторые отсутствующие индексы.
вот интересно, он из обычного индекса быстрее будет выбирать, чем из кластеризованного?
с другой стороны, кластеризованный состоит из обычных индексов, так что не факт.
с третьей стороны - чего тогда ругается? )
andrewks хотя он всё равно ругается на некоторые отсутствующие индексы.
если запрос будет с фильтром по одному полю - индекс будет эффективный.
Другой вопрос, что не всегда ругается и не всегда эффективно (условие по 2м полям)
andrewks кластеризованный состоит из обычных индексов,
это откуда инфа?
andrewks ну, именно в этом случае индекс же был в пролёте )
неее, у меня индекс был в пролете, потому что я условие по периоду не сделал.
вообще про кластерный написано про кластерный:
"Creates an index in which the logical order of the key values determines the physical order of the corresponding rows in a table. "
"Создает индекс, в котором логический порядок значений ключа определяет физический порядок соответствующих строк в таблице."
т.е. когда условие по периоду я добавил оно и понятно, что index seek (отобрал записи по периоду и среди них уже скан). ну опять же вывод можно сделать как
admin govnoforuma Отсюда вывод: не важно в каком порядке стоят измерения.
ладно, я еще один эксперимент проведу: два измерения, одинаковая селективность, записей побольше сделаю.
и отдельно по каждому отбор.
andrewks почему оно серенькое (_Period)
где?
+(127) у меня 91 тыс записей. для чистоты эксперимента до 900тыс сейчас догоню.
(127) Скажем так, особо не вникал. Слишком много условий нужно проверять, состав реквизитов, состав индексов, да на различных объемах, прочее влияющее. Но рекомендации, про "сдвинуть ближе к началу часто используемое", читал, прочитанному верю. Влияет. Но влияет как? - на одном запросе - туда (быстрее), а на другом, к этому же регистру, но с другим составом вытягиваемых данных - обратно (медленнее). И что мы будем с этим делать?
Идун а на другом, к этому же регистру, но с другим составом вытягиваемых данных - обратно (медленнее)
сомнительно ) да и сабж другой. это тема другого срача
все, порядок не только важен, но и важно накладывая условия накладывать на измерения сверху вниз без пропусков:
т.е. если регистр: склад - номенклатура- серия,
а у вас есть только склад и серия, то запрос выполнится быстрее , если дополнительно указать номенклатуру.
(136) почему?
