Поясните знающие камрады. Если в запросе только 1 условие результат моментальный, 100 миллисекунд, если добавить еще условия то запрос выполняется уже раз в несколько медленнее.
Вот пример:
ВЫБРАТЬ
    КОЛИЧЕСТВО(CRM_ВзаимодействияСКлиентом.Период) КАК Период
ИЗ
    РегистрСведений.CRM_ВзаимодействияСКлиентом КАК CRM_ВзаимодействияСКлиентом
ГДЕ
    CRM_ВзаимодействияСКлиентом.Ответственный = &Ответственный //Условие 1
    И CRM_ВзаимодействияСКлиентом.ПодразделениеОтветственного = &ПодразделениеОтветственного //Условие 2
    И CRM_ВзаимодействияСКлиентом.СтатусРегистратора = &СтатусРегистратора //Условие 3

Если оставить только "Условие 1" - быстро, если добавить еще 2 и 3 то медленно. Почему?
Все поля в условиях индексированные.
Это норма или что то не так работает?

А виртуальными таблицами почему не пользуетесь?

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

статистика живая? или база вообще файловая?

(1) А как и какими виртуальными таблицами в данном случае?

(0) Статистика?

(0)
mdop=0
или
статистика

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

Может еще какие индексы есть, структуру можно.

Попробуйте запрос с тремя условиями раздилить на объединить 3 запроса и в каждом по одному условию, будет быстрее или так же?

1C:CRM, редакция 3.0 (3.0.7.1) я такого запроса не нашел.

Ой такого регистра

(5) (6) Возможно статистика. Не могу пока сказать, доступа к скулю нет.
mdop=0  - это что?

(9) там И, а не ИЛИ

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

(0) >>Все поля в условиях индексированные.

Для поиска по индексу - эти поля должны входить в один индекс. А если эти поля - реквизиты/ресурсы, то по каждому полю строится свой,  отдельный индекс: Поле+Измерение1-N

Поэтому одно условие (по одному полю) может быстрее отрабатывать.

покажите скрин структуры регистра по измерениям

(7) В нем много полей и записей около 60 миллионов. Почти все поля индексированы.
Вот структура. Желтым индексные поля.
https://i.imgur.com/hVaRqK7.png

(17) Индексы не работают :)

https://its.1c.ru/db/metod8dev/content/1590/hdoc

+ навсякой

Регистр сведений
Непериодический регистр сведений
Индекс

Условие и описание

[ОРРХ | ОРНР1 +] Измерение1 + [Измерение2 +...] (Кластерный)

Есть хоть одно измерение регистра.
Индекс, включающий все измерения в том порядке, в котором они заданы при конфигурировании.
Индекс кластерный, если регистр независимый.

[ОРРХ | ОРНР1 +] ИзмерениеN + Измерение1 + [Измерение2 +...]

Измерению "ИзмерениеN" задано свойство "Индексировать" или свойство "Ведущее" и при этом это не первое и не единственное измерение.
Индекс, включающий все измерения. Первое поле - ИзмерениеN, затем все остальные измерения в том порядке, в котором они заданы при конфигурировании.

[ОРРХ | ОРНР1 +] Реквизит + Измерение1 + [Измерение2 +...]

Реквизиту "Реквизит" задано свойство "Индексировать".
Индекс в котором первое поле - Реквизит, затем все измерения в том порядке, в котором они заданы при конфигурировании.

[ОРРХ | ОРНР1 +] SimpleKey

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

[ОРРХ | ОРНР1 +] Ресурс + Измерение1 + [Измерение2 +...]

Ресурсу "Ресурс" задано свойство "Индексировать".
Индекс в котором первое поле - Ресурс, затем все измерения в том порядке, в котором они заданы при конфигурировании.

Периодический регистр сведений
Индекс

Условие и описание

[ОРРХ | ОРНР1 +] Период + [Измерение1 + ...] (Кластерный)

Всегда.

[ОРРХ | ОРНР1 +] Измерение1 + [Измерение2 +...] + Период

Есть хоть одно измерение регистра.
Индекс, включающий все измерения в том порядке, в котором они заданы при конфигурировании и поле Период.

[ОРРХ | ОРНР1 +] ИзмерениеN + Период + Измерение1 + [Измерение2 +...]

Измерению "ИзмерениеN" задано свойство "Индексировать" или свойство "Ведущее" и при этом это не  единственное измерение.
Индекс, включающий поле Период и все измерения. Первое поле - ИзмерениеN, затем поле Период, затем все остальные измерения в том порядке, в котором они заданы при конфигурировании.

[ОРРХ | ОРНР1 +] Реквизит + Период + [Измерение1 + ...]

Реквизиту "Реквизит" задано свойство "Индексировать".
Индекс в котором первое поле - Реквизит, затем поле Период, затем все измерения в том порядке, в котором они заданы при конфигурировании.

[ОРРХ | ОРНР1 +] Ресурс + Период + [Измерение1 + ...]

Ресурсу "Ресурс" задано свойство "Индексировать".
Индекс в котором первое поле - Ресурс, затем поле Период, затем все измерения в том порядке, в котором они заданы при конфигурировании.

Предположение 1. Старая статистика. SQL решает использовать другой индекс, получает по нему кучу записей, гораздо больше чем планировалось. И как следствие появляется неоптимальный скан для проверки остальных условий.
Предположение 2. Такой запрос исполняется не первый раз, причем до этого с другими параметрами он был быстрее. С этими параметрами старый план оказался неоптимальным с теми же сканами для проверки условий.