ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ ПЕРВЫЕ 3064 // если здесь написать 3065 или больше - сразу тормоза
    Источник.ПолеСтрока КАК ПолеСтрока
ПОМЕСТИТЬ втТаблица
ИЗ
    Источник КАК Источник

ИНДЕКСИРОВАТЬ ПО
    Поле1
;

////////////////////////////////////////////////////////////////
ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ПереодическийНезависимыйРегистр.Измерение1 КАК Измерение1
ИЗ
    РегистрСведений.ПереодическийНезависимыйРегистр КАК ПереодическийНезависимыйРегистр
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ втТаблица КАК втТаблица
        ПО ПереодическийНезависимыйРегистр.Измерение1 = втТаблица.ПолеСтрока
ГДЕ
    ПереодическийНезависимыйРегистр.Ресурс = "что-то"

Второй запрос (где поиск по регистру) проходит быстро (десятые секунды), если в первой таблице меньше 3065 строк, если больше, сразу тормоза (15 секунд). Что можно сделать?
План запроса проанализировать нет возможности.

То есть надо просто из регистра сведений "ПериодическийНезависимыйРегистр" отобрать Значение "Измерений", отфильтровав их. И все. Первую таблицу описал просто для наглядности.

скорее всего что первые 3064 лежат в начале тиаблицы, а остальные в конце

(0) > План запроса проанализировать нет возможности.
Структуру метаданных проанализировать нет возможости. Извини.

(3) я же описал структуру метаданных, чего не хватает?

Поле "ПереодическийНезависимыйРегистр.Измерение1" в конфигураторе не индексировано. Тип - строка(36)

измерение1 никогда и не индексируется дополнительно

(6) почему?)

потому что оно входит в составной индекс

Если у тебя в измерениях длинные строки, то ты ССЗБ
А так напрашивается
ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ПереодическийНезависимыйРегистр.Измерение1 КАК Измерение1
ИЗ
    РегистрСведений.ПереодическийНезависимыйРегистр КАК ПереодическийНезависимыйРегистр
ГДЕ
    ПереодическийНезависимыйРегистр.Ресурс = "что-то"
    И ПереодическийНезависимыйРегистр.Измерение1 В (ВЫБРАТЬ ПолеСтрока ИЗ Источник)

(0) прикольно. А если условие после ГДЕ  перенести в соединение?

(0)Уже то , что в запросе есть "ИНДЕКСИРОВАТЬ ПО     Поле1"
говорит о многом.
Как Вы думаете зачем в правилах форума есть рекомендации указывать версии по ?

(9) странный совет

(8) Измерение1 надо индексировать если есть ещё Измерение2
т.к. запрос без периода в периодическом регистре

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

(0) попробуйте отобрать в ВТ регистр по условию, а потом уже внутреннее соединение. Конечно так себе метод, но попытка не пытка

(14) некоторые это рекомендуют

(4) Начем с ограничений RLS, порядка измерений и наличия индекса по Ресурс1

(16) ну надо же понимать для чего

(15) И это мой совет странный. Мой совет лишь дает больше свободы оптимизатору запросов, а твой подразумевает конкретные расклады, которых ты знать не можешь.

2) можно ещё Ресурс проиндексировать на всякий случай
3) соединять надо таблицу где мало данных к таблице где много данных(строк)
4) соединять по колонке с типом "строка" это плохо, надо что-то переделать чтоб была не строка

(20) скажи как ты думешь происходит соединение на стороне скл?

5) если регистр периодический - значит вам нужен СрезПоследних а не все данные

(22) может ТС нужно по дням инфу получать?

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

(24) те только 1 вид соединения бывает?

(23) в итоге может получиться следующая портянка, на каждый день для 100500 строк идет соединение с 100500 строк первой таблицы, где еще может быть 2 измерения, а соединение по 1. А дней в выборке может быть пару лет в разрезе дня)

(22), (24) Вау, круто! А напиши что-нибудь еще по-своему, по-программистки!

(24) Байки из склепа какие-то.

(0) Вы что от этого периодического регистра получить хотите? Данные в разрезе периода дополненные из источника?

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

Я уже десятки таких ситуаций у себя в системе исправлял

(22) срез последних тоже живет своей жизнью. Лучше написать по основной таблице, если есть возможность

ИТС: "Не используйте индексирование по строковым полям, суммарная длина которых превышает 300 символов. "

Вы делаете так как запрещено поэтому тормозит :-)

(18) рекомендация отсюда https://youtu.be/IxmXvsbi6-Q?t=2227

ещё с сайта 1С ИТС:
"использование длинных строк в измерениях регистров может существенно сказаться на производительности системы."

(32) Чуви, ты 300 символов и 36 можешь сравнить?

ВЫРАЗИТЬ(Источник.ПолеСтрока КАК СТРОКА(512)) КАК ПолеСтрока

(36) ну и убрать индексирование

(36) Дядь Дим, и ты туда же. Зачем из строки, длиной в 36 символов делать строку в 512?

Длина строки написана в (5) если что.

(39) 1)в одной таблице 36 символов а в другой неизвестно ещё
2) раз 36 символов - значит это ГУИД, значит это есть такой справочник или документ с этим ГУИД,
значит в регистре хранить надо ссылку на справочник а не ГУИД :-)

(30) Я предложил для начала отпустить вожжи и посмотреть не станет ли лучше. Работая оптимизатором самому нужно как минимум понимать, что именно ты оптимизируешь. От ТС нет подробностей по характеру наполнения таблиц, поэтому твои советы тоже не претендуют на большее, чем гадание на кофейной гуще.
ЗЫ. Глядя на твои крайне негативные отзывы про работу оптимизатора, у меня два вопроса. У тебя postgresql? Ты статистику пересчитывать пробовал?

(41) Он менял запрос и статистика пересчитывалась сама :-)