Регистр сведений, в нем ресурс типа строка.
Подразумевается что будут выполянться запросы к этому регистру, с отбором по этому ресурсу или использованием ПОДОБНО
Если поставить индекс, ускорит ли это выполнение запроса?

Зависит от запросов

Если подразумевается, что про строковому ресурсу будет использоваться ПОДОБНО, то в консерватории уже что-то не так.
Индексы по большим строкам и отборы по ним - тоже ошибка в консерватории.

Строка в ресурсах это сильно

(0) Индекс ПОДОБНО не ускоряет.

Кстати читал что индекс по ресурсу на самом деле означает индекс по "ресурс плюс все измерения", вот нафига это вообще сделано?

(4) а просто отбор ускоряет?

(4) Ускоряет, если с начала строки поиск.

(6) https://its.1c.ru/db/metod8dev#content:1590:hdoc
[ОРРХ | ОРНР1 +] Ресурс + Измерение1 + [Измерение2 +...]
Ресурсу "Ресурс" задано свойство "Индексировать".
Индекс в котором первое поле - Ресурс, затем все измерения в том порядке, в котором они заданы при конфигурировании.

(8) А кто-нибудь может объяснить, зачем раздувать индекс комбинацией измерений, если надо всего лишь отбирать по ресурсу или реквизиту? Чем руководствовались в 1с?

Ресурс, по которому происходят отборы, называется измерение.

(9) > Чем руководствовались в 1с?
"Доступно и всерьез" (с)
https://www.youtube.com/watch?v=5mFVnwHO-ec

(10) +1
(9) Чем руководствуется 1с-ник, который делает отборы по ресурсу?

(0) расскажи, что это за ресурс

(10) А Кодер-а, подобное утверждающего, называют, но не вслух

(10) ответ неверный

(9) ну вам же помимо самого ресурса нужны еще какие-то данные из этой таблицы? как думаете, где их быстрее взять из этого индекса или сходить за ними в саму таблицу?

(16) Это всё (получение данных непосредственно из индекса) возможно работает, если использовать один запрос. А если искать через код 1с отборами, а потом обращаться - то лишняя работа для sql-сервера и лишнее занимаемое место.

(9) Вопрос - огонь! https://docs.microsoft.com/en-us/sql/2014-toc/sql-server-index-design-guide?view=sql-server-2014
The row locators in nonclustered index rows are either a pointer to a row or are a clustered index key for a row, as described in the following:
If the table has a clustered index, or the index is on an indexed view, the row locator is the clustered index key for the row.
Дальше продолжать?

(18) продолжай

(12) например в типовом регистре Штрихкоды, измерение Штрихкод, ресурс Номенклатура. Происходит отбор по номенклатуре, чтобы вывести штрихкод в справочнике Номенклатура.

(12) ооо, в этом типовом регистре у ресурса Номенклатура стоит Индексировать.

(14) Не придирайся. Да, терминологически неверно, но мой способ не вреден базе.
(20) Тип там, надеюсь, не строка(200)?

(22) > но мой способ не вреден базе.
твой способ очень ОЧЕНЬ базе, а точнее, архитектуре

(0) ускорит чтение, см (7), но замедлит запись.

(9) Я забыл, как это называется правильно. Покрывающие индексы или как-то так.
Суть в том, что после применения индекса нужно еще и получить данные из соответствующих строк. А когда этих данных нет в самом индексе - это довольно дорогая операция, сильно снижающая эффективность использования индекса.

(25) + По сути получается, что размер данных увеличивается во столько раз, сколько таких индексов используется (и запись замедляется). Зато каждый индекс работает почти как кластерный по эффективности.

(3) а где строке быть? в измерениях?

(12) Вы слишком вошли в кураж)
такие задачи бывают

(12) Это методический вопрос - что к чему привязано. В одном процессе автомобили у водителей, в других - есть ответственные за автомобиль.
А регистр будет один и не получится сделать два измерения. РС распухнет. Если  в одной машине одно водительское кресло, то измерениями будут Авто.

Хотя по водилам запросов будет больше и шире

ибо авто - это рабочие центры. Методически.

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

(25) Это называется RID Lookup (для кучи) или Key Lookup (для кластерного индекса).
(19) Key lookup возможен только по всем ключам кластерного индекса, а в регистре это все измерения. Таким образом, все измерения будут присутствовать в любом некластерном индексе.

(33) но ключ кластерного индекса хранится только в листьях некластерного индекса

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

(5) потому что отбор редко бывает по одному полю, обычно по набору измерений

(9) при правильном проектировании отбор всегда будет накладываться по всем измерениям, или хотя бы по их большинству

(35) ты какое утверждение подтверждаешь или опровергаешь?

(36) То есть 1с в очередной раз не дает выбора. Жрите что дают. Хотите быстрый поиск по ресурсу и реквизиту - а вот вам хрен, получите в довесок кортеж всех измерений.

(39) Да и вообще, галочка "Индексировать" - семерочный атавизм. Следовало бы дополнительные индексы ввести как отдельную сущность объекта метаданных, чтобы можно было создавать произвольные индексы по произвольному сочетанию реквизитов, измерений и ресурсов - при необходимости. И чтобы это можно было делать в том числе в расширениях.

(40) Какие у тебя были реальные задачи, где была такая необходимость?

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

(40) и без этого есть уникумы, которые врубают индексирование "про запас"

(42) это всё от кривой архитектуры

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