Подскажите, если кто-то когда-то анализировал...
Имеется довольно большой справочник договоров (~500 тыс. записей). Организован, условно говоря, "по-дурацки" - частью наименования является некий условный год, т.е. выглядит примерно так: "Договор №117 об оказании каких-то услуг за 2017 год третьего типа". С какого-то момента станадартный поиск  (фильтр) по строке "2017" (часть наименования) стал выполняться довольно медленно, около 30 сек. База клиент-серверная, платформа 8.13, используется RLS.
Собственно вопрос: введение доп. реквизита типа число(4,0) может существенно ускорить поиск? Какие ещё варианты возможны без программирования. Конфигурация на поддержке, и даже расширение почему-то воспринимается "в штыки"?
К базе сейчас доступа нет, экспериментально не проверишь, если кто-то знает заранее - поделитесь знаниями.

полнотекстовый проверить.
если 30 сек из-за РЛС,когда идет полный перебор,то доп.реквизит ничего не исправит.

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

Индексированный доп. реквизит шапки будет работать быстро, если запрос будет по условию LIKE "117*" (без первой звёздочки)

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

(3) Ну, я думал тогда уж нечто совсем специализированное... Новый реквизит "Ваш долбаный год для быстрого поиска" (и больше можете не запихывать его в наименование договора): Число(4,0).  Тогда вообще летать должно, наверное.

(4) RLS обычный по организации. Под админискими правами типовой поиск не тормозит

(6) очень много инфы. При том, что название конфигурации не указано.
И под админскими правами рлс отсекается своим условием.

(7) Да. Был как-то случай, продвинутый юзер навытаскивал в форму списка номенклатуры допреквизитов. А потом жаловался как эта ваша 1с дико тормозит при поиске.

(0) Это же легко проверить, а так все зависит сколько и какие доп реквизиты у этого справочника уже используются, тк это отдельная таб часть, (ну если про БСП), то скорее всего там элементов будет больше чем 500к, если вообще нет и еще не у всех элементов будешь устанавливать, конечно ускорит

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

Проверьте индекс ППД. Попробуйте удалить и пересчтитать индекс. Убедитесь, что обновление и слияние настроены корректно.
500 000 - не такое уж это и большое количество для полнотекстового поиска.
Подтормаживать конечно может, но не настолько, чтобы по 30 секунд искать. Очень уж похоже, что поиск производится без использования ППД.

(7) БП 3.0
(9) баз пока что недоступна, проверяю "мысленно"
(11) последний раз вроде всё в порядке было с индексом. Я тоже полагал, что 500000 записей немного
Да, не смотрел запрашивал характеристики железа. Но по "ощущениям" вряд ли какой-то отстой
Спасибо откликнувшимся!

(11) Использование ППД для оперативной работы - зло, ибо не приспособлено для этого в силу своей асинхронной природы. Вот если бы обновление индекса проходило не по расписанию, а триггером при изменении индексируемого реквизита - тогда был бы толк.