Привет.

Есть дин.список документов (заказов клиенту), в произвольном запросе (упрощенно), к списку документов левым соединением приклеен регистр сведений - измерение ЗаказКлиенту (индекс стоит) и вытащено 2 ресурса:
1) Состояние оплаты (индексируется, тип - перечисление)
2) Статус обработки (не индексируется, тип составной - 2 перечисления).

При отборе в дин.списке по первому ресурсу - вешается, по второму - работает быстро. Выборка записей получается примерно одинаковая. Платформа 8.3.9.1818 (х86).

Наоборот, я бы понял. Почему так и что делать?

потому что тип составной и идет куча неявных соединений - уменьшай их количество

(1) невнимательно прочитал. На составном типе без индексации работает БЫСТРЕЕ, чем на простом типе с индексацией.

Собственно в этом и вопрос.

Какая кардинальность по Состоянию оплаты?

(0) Я бы посмотрел какой запрос формируется из динамического списка

(3) что вы понимаете под словом "кардинальность" в этом контексте?

(4) подозрение на вставку отбора в область "где" была. Пробовали параметром засунуть отбор во временную таблицу регистра - не помогло.

индексация хорошо отработает на больших объемах
на малых - затраты время на индексацию и тормоза

(7) объемы очень большие. База 2 ТБ. Индекс оправдан.

(6) я имею в виду, что динамический список - это СКД, я бы сделал похожий отчет в СКД и проанализировал бы запросы в том и другом случае. Это если неохота с ЖР и профайлером неохота возиться

Можно еще глянуть индексы, которые система построила для РС, и попробовать в них попасть в случае тормозов

(9) до профайлера не добраться, SQL за семью печатями. Попробую на СКД, но опять же не очень понятно что там можно увидеть.

(0) sql использует не тот индекс. Смотрите профайлер.

(3) около 2000 строк

(5) https://en.wikipedia.org/wiki/Cardinality_(SQL_statements)

Случайно не срез последних?

(14) тип "перечисление" - всего 3 значения + пустое. Ну т.е. индекс по этому полю не имеет смысла?

(15) срез.

Итоги для среза используются?

(16) Левое соединение с виртуальной таблицей как-то не кошерно

(17) - нет.
(18) - если динамическое считывание, то пакетных запросов нет - какие варианты?

2(16) Да, не имеет. Очень низкая кардинальность. Имеет смысл для например от 20, чтобы вероятность каждого отдельного значения была не больше 5%.
Потому что иначе случаются нестед-лупы. С одной стороны - хорошо что этих значений не много, но если записей в которых они есть дофига, и в кажой происходит нестед-луп, то производительно резко деградирует