Странные тормоза в динамическом списке

1С v8

21.12.16

✎

11:03

Привет.

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

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

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

1 DrShad

21.12.16

✎

11:22

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

2 Nik_nik_nik

21.12.16

✎

11:38

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

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

3 Живой Ископаемый

21.12.16

✎

11:42

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

4 impulse9

21.12.16

✎

11:44

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

5 Nik_nik_nik

21.12.16

✎

11:44

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

6 Nik_nik_nik

21.12.16

✎

11:45

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

7 FIXXXL

21.12.16

✎

11:47

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

8 Nik_nik_nik

21.12.16

✎

11:48

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

9 impulse9

21.12.16

✎

11:52

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

10 impulse9

21.12.16

✎

11:54

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

11 Nik_nik_nik

21.12.16

✎

11:56

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

12 H A D G E H O G s

21.12.16

✎

12:10

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

13 Nik_nik_nik

21.12.16

✎

12:18

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

14 Живой Ископаемый

21.12.16

✎

12:21

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

15 Вафель

21.12.16

✎

12:22

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

16 Nik_nik_nik

21.12.16

✎

12:47

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

(15) срез.

17 Вафель

21.12.16

✎

12:51

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

18 Cool_Profi

21.12.16

✎

12:51

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

19 Nik_nik_nik

21.12.16

✎

13:54

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

20 Живой Ископаемый

23.12.16

✎

11:41

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