Имя: Пароль:
1C
1С v8
Странные тормоза в динамическом списке
0 Nik_nik_nik
 
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
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%.
Потому что иначе случаются нестед-лупы. С одной стороны - хорошо что этих значений не много, но если записей в которых они есть дофига, и в кажой происходит нестед-луп, то производительно резко деградирует