Конфигурация УНФ 1.6.19.215
Использую характеристики номенклатуры и доп реквизиты характеристик.
Допреквизиты это табличная часть элемента справочника характеристики.
В этой ТЧ есть колонки Свойство и Значение
Характеристик много.
Нужно быстро находить характеристику по допреквизиту.
Пользовался запросом по ТЧ справочника характеристики.

        ВЫБРАТЬ
            ХарактеристикиНоменклатурыДополнительныеРеквизиты.Ссылка КАК Ссылка
        ИЗ
            Справочник.ХарактеристикиНоменклатуры.ДополнительныеРеквизиты КАК ХарактеристикиНоменклатурыДополнительныеРеквизиты
        ГДЕ
            ХарактеристикиНоменклатурыДополнительныеРеквизиты.Свойство = &Свойство
            И ХарактеристикиНоменклатурыДополнительныеРеквизиты.Значение = &Значение

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

Индексировать колонку Значение.

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

(1) Да, она не индексируется. Попробую. Спасибо.

(1) А если внесу изменения через расширение сработает? И как проверить что это работает?

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

надо писать ВЫРАЗИТЬ(-:)

(6) не нужно

(1) может лучше индексировать Свойство? Значение скорее всего составного типа. Платформа нафигачит по нему лишних индексов (на каждый примитивный тип по индексу, плюс индекс для ссылочных типов)

(8) так свойство наверняка у каждой характеристики есть

(8) нет

(1) Не включается индексировать, появляется ошибка.

Но, индексировал колонку Свойство и произошло чудо, скорость выполнения запроса выросла в 22 раза.
Вот только как это скажется на размере базы?

(9) не факт. Кстати, индексируя поле составного типа, в котором есть примитивные типы, можно попасть в хитрую платформенную ловушку. Платформа в SQL-запрос неявно добавляет отборы по примитивным полям составного типа

WHERE
...
and <Поле даты> = 'пустаядата'
and <Поле строки> = ''
and <Поле числа> = 0

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

(12) почти не скажется

(13) Ты хочешь сказать, что в этом случае для индексации одного поля 1С создается несколько индексов SQL?

(15) да. По крайней мере так было в 8.2. А в более старых платформах, может ранние 8.2 или 8.1, если в субконто добавить поле примитивного типа, то платформа создавала 100500 лишних индексов

(13) Скуль начинает творить трэш, когда у него нет актуальной статистики.

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

(15) Давно уже нет.
Но если база древняя и в ней никогда не делали полную реструктуризацию - могут ещё быть индексы созданные по старой схеме.

(16) Я посмотрел.
Ты устарел, там уже давно один индекс, типа https://ibb.co/JQ3LLQx

Странно. Мне почему-то казалось, что дело не в версии платформы 1С, а в версии MS SQL сервера. На старых версиях SQL платформа создавала множество индексов. Впрочем могу ошибаться.

(20) сейчас один. Но хорошего тоже мало, у тебя в составном индексе вклинилось число

(21) скуль не решает, какие индексы должны быть у таблиц

(22) 1С поставит в условие равенство на ноль да и всё.

(22) > вклинилось число
Ну ты ж сам пример условия в (13) приводил

(23) ошибаетесь https://docs.microsoft.com/en-us/sql/tools/dta/lesson-2-using-database-engine-tuning-advisor?view=sql-server-ver15

(26) Адвизор != решатель.
Такшта...

(24) это примерно как индекс по организации. Если в табличке 98% записей с одной и той же организацией, то толку от индексирования по полю Организация никакого

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

Регистр №1
Склад    Номенклатура
Склад №1    Товар А
Склад №1    Товар Б
Склад №1    Товар В
Склад №2    Товар А
Склад №2    Товар Б
Склад №2    Товар В
Склад №2    Товар Г
Склад №2    Товар Д

Регистр №2
Число    Склад    Номенклатура
0    Склад №1    Товар А
0    Склад №1    Товар Б
0    Склад №1    Товар В
0    Склад №2    Товар А
0    Склад №2    Товар Б
0    Склад №2    Товар В
0    Склад №2    Товар Г
0    Склад №2    Товар Д


допустим, запросом нужно выбрать Товар Б на Склад №1

условно ползём по составному индексу регистра №1 (Склад + Номенклатура): -> 3 записи Склад №1-> 1 запись Товар Б
условно ползём по составному индексу регистра №2 (Число + Склад + Номенклатура): -> 7 записей 0 -> 3 записи Склад №1 -> 1 запись Товар Б

чувствуешь лишние движения? К слову, самым эффективным было бы вот такое следование изменений

Номенклатура    Склад
Товар А        Склад №1
Товар Б        Склад №1
Товар В        Склад №1
Товар А        Склад №2
Товар Б        Склад №2
Товар В        Склад №2
Товар Г        Склад №2
Товар Д        Склад №2

тогда вхуж по индексу будет выглядеть так: -> 2 записи Товар Б -> 1 запись Склад №1

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

(28) https://youtu.be/tBONXbtiIR8

(28) Рекомендую почитать про индексы.

(28) Вот тестовая конфигурашечка,
https://disk.yandex.ru/d/45CNPsUPHvTkjg

В тестовой обработке понажимай кнопки, и посмотри на планы запросов по кнопкам "Запрос к первому регистру" и "Запрос к второму регистру"

(28) > условно ползём по составному индексу

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

(33) это не отменяет факта что высокоселективные поля лучше первыми в индексе иметь

(34) Да, но это всего лишь уменьшает глубину просмотра, а не "ползём по индексу"

(32) и что план? План может выдать Index Seek, а запрос всё равно будет тупым. Видимо у тебя нет опыта работы с большими БД, раз ты так бравируешь планами запросов

(33) дяденька, давай я не буду тебе рассказывать про селективность индекса?

(35) ты заблуждаешься

(36) Вам бы еще про чтение планов запросов почитать.

**записал Конструктор1С в списочек.

(37) > Конструктор1С

Возрастное ограничение: от трех до пяти лет =)

(38) "А я за час собрал!"

(36) IndexSeek может быть плох, когда у него есть остаточный предикат поиска. Надеюсь, вы в курсе этого.

(36) Вот тебе пример остаточного предиката, когда indexseek может быть не так полезен, и это могло нанести травму
https://prnt.sc/1t7ur16

Обновленная база с 3 регистром, где это воспроизводится.
https://disk.yandex.ru/d/45CNPsUPHvTkjg

(40) нет. Index Seek может быть плох и в других случаях, и даже без предиката where. Один из них это фильтр по неселективному полю. Например, в документе индексирован реквизит Организация. Но во всех документах одна и та же организация. Производительность в труху
Второй пример. В таблице есть два индекса, по Организация и Контрагент. В запросе накладывается отбор по обоим полям. НО! В таблице по отбираемому контрагенту 1 тыс. записей, а по отбираемой организации 1 млрд. записей. Скуль бодро отрапортует о двух Index Seek без where, а потом начнёт джойнить их результаты. Производительность снова в труху. Гораздо выгоднее было бы, если бы индекса по организации не было. Тогда Index Seek по контрагенту отобрал бы тыщу, а предикат where быстренько дофильтровал по организации

(42) В первом случае индекс не будет использоваться, если в выборке есть поля, отличные от ИНН и Ссылка и это правильно.
И будет использоваться, если есть только эти поля и это тоже правильно.

(42) во втором случае - да, такое бывает и это лечится предварительным отбором во временную таблицу по более селективному индексу. Такой себе костыль, но в условиях отсутствия конструктора индексов - шо маемо.