Согласно стандартам 1C не рекомендуется использовать конструкцию ИЛИ в запросах.

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

такой вариант не работает
Док.Комментарий ПОДОБНО ("%*.jpg%","%*.mp4")

остается или конструкция с "выбор когда" или писать условие "ИЛИ" ? Какие еще есть варианты ?

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

пишите ИЛИ, не слушайте 1С
делайте, как Вам надо

Они обычно рекомендуют заменять ИЛИ на ОБЪЕДИНИТЬ.

ИЛИ может быть безвредным, если оно является аналогом В()

Контрагент = &Контрагент1 ИЛИ Контрагент = &Контрагент2

аналогично

Контрагент В(&Контрагент1, &Контрагент2)

в таком случае индекс по контрагенту может быть использован

А что комментарий у вас проиндексирован? Обычно это строка неограниченной длины

(4) Если знак процента впереди, то индекс не поможет

(3) Автор ветки ищет по полю "Комментарий". Во всех (или почти во всех) типовых это реквизит с типом "строка неограниченной длины". Вряд ли тут вообще стоит вопрос об использовании индексов.

такие запросы к таким полям точно надо строить так:
выбрать
где
Комментарий ПОДОБНО "%*.jpg%"
ОБЪЕДИНИТЬ
выбрать
где
Комментарий ПОДОБНО "%*.mp4%"

али так:

выбрать
поместить вт1
где
другие нормальные условия сужающие диапазон
;
//
выбрать вт1
где
вт1.Комментарий ПОДОБНО "%*.jpg%"
ОБЪЕДИНИТЬ
выбрать вт1
где
вт1.Комментарий ПОДОБНО "%*.mp4%"

(7) Какой в этом смысл если поле не индексировано? Будет скан таблицы, а в вашем случае с объединить еще и дважды

(8) Ещё разок повторю. Если впереди процент, то индексация поля не поможет.

поле LIKE "mp4%" // индекс поможет

поле LIKE "%mp4%" // индекс не поможет

(9) Если СУБД скуль, то поможет
И вопрос вообще не в %, а в том что человек слышал про стандарты разработки, но не понимает почему так рекомендуется
Если у него это поле не индексировано, то и задаваться вопросом оптимизации смысла нет, тем более выполнять рекомендации из (7)

(10) https://habr.com/ru/articles/655555/

Однако, поиск по индексу не будет задействован если использовать вот такие предикаты:

ABS(a) = 1
a + 1 = 9
a like '%abc'

нету там индексов.
остаётся понять, насколько криво будет работать конструкт вида
комментарий подобно &шаблон1 или комментарий подобно &шаблон2

при наличии условий, которые попадают в индекс, но рядом такая штука (12) что будет делать скуль? воспользуется индексом и потом посчитает LIKE или в лоб запустить фулскан?

(11) А если попробовать?

SELECT
T1.Ссылка,
T1.ИдентификаторПлатежа
FROM Документ.РеализацияТоваровУслуг T1
WHERE ((T1.ОбластьДанныхОсновныеДанные = ?)) AND ((T1.ИдентификаторПлатежа LIKE ?))
p_0: 0N
p_1: '%1904НР000000270000%'

Index Seek(OBJECT:([ERP].[dbo].Документ.РеализацияТоваровУслуг.[Индекс по ОбластьДанныхОсновныеДанные, ИдентификаторПлатежа, Ссылка] AS [T1]), SEEK:([T1].[ОбластьДанныхОсновныеДанные]=[@P1] AND [T1].[ИдентификаторПлатежа] > [Expr1004] AND [T1].[ИдентификаторПлатежа] < [Expr1005]),  WHERE:([ERP_AtolDrive_copy].[dbo].Документ.РеализацияТоваровУслуг.[ИдентификаторПлатежа] as [T1].[ИдентификаторПлатежа] like [@P2]) ORDERED FORWARD)

Частичный SEEK по ИдентификаторПлатежа присутствует

SELECT
T1.Ссылка,
T1.ИдентификаторПлатежа
FROM Документ.РеализацияТоваровУслуг T1
WHERE ((T1.ОбластьДанныхОсновныеДанные = ?)) AND ((T1.ИдентификаторПлатежа LIKE ?) OR (T1.Ссылка = ?))
p_0: 0N
p_1: '%1904НР000000270000%'
p_2: 0x97FF00155D018B2D11E961ACBDF87DFD

А вот это уже фактически скан

Index Seek(OBJECT:([ERP].[dbo].Документ.РеализацияТоваровУслуг.[Индекс по ОбластьДанныхОсновныеДанные, ИдентификаторПлатежа, Ссылка] AS [T1]), SEEK:([T1].[ОбластьДанныхОсновныеДанные]=[@P1]),  WHERE:([ERP_AtolDrive_copy].[dbo].Документ.РеализацияТоваровУслуг.[ИдентификаторПлатежа] as [T1].[ИдентификаторПлатежа] like [@P2] OR [ERP_AtolDrive_copy].[dbo].Документ.РеализацияТоваровУслуг.[Ссылка] as [T1].[Ссылка]=[@P3]) ORDERED FORWARD)

(14) Что Вы нам планы показываете? Мы пробовали на таблице в 10 млн записей. Процент впереди тормозит запрос, несмотря на индексы

(14) Этот предикат остаточного поиска сломался, несите следующий
https://disk.yandex.ru/i/eeqalHa1MLOpBA
https://disk.yandex.ru/i/XjxebgjYMniyNA

(14) это не настоящий seek, а Index Seek - range scan https://stackoverflow.com/questions/18065994/how-can-like-seek-on-an-index

(15)(16)(17) Согласен, если % вначале строки поиска, то фактически читает всю таблицу

(0) используй вместо запроса полнотекстовый поиск...

(19) По крайней мере попробуй..

(7) ОБЪЕДИНИТЬ ВСЕ если не требуется группировка

(0) чем не устраивает обычный
(Док.Комментарий ПОДОБНО ("%*.jpg%") ИЛИ Док.Комментарий ПОДОБНО ("%*.mp4"))
?

От условий задачи надо исходить. Может и вовсе придётся в РС перекируть этот комментарий, предварительно его заполнив частями по 500-1000 в несколько потоков транзакциями, или вынести все это добро в доп реквизит "расширение файла"

Кстати пару дней назад с "подобно" стояла задача. Начинается не с %, а со строковой литералы, индекс по идее должен работать. Поле проиндексировано, все ок. Запрос выполняется 6 секунд, хоть убейся, объединения, реиндексация, ребилд. Если ставит равенство вместо подобно - милисекунды. Перенесли в РС, левое соединениена равенство и готово, сократили закрытие на часы.

(24) По одному символу индекс работает плохо.