Как оптимизировать запрос в динамическом списке платформы 1С?

[Odineski]

Можешь оптимизировать запрос динамического списка?

[Odin — Одинэсник]

Да. Для оптимизации нужен сам запрос и настройки динамического списка. Пришлите:

1. Текст запроса из свойства динамического списка.
2. Версию платформы 1С и конфигурацию.
3. Какие таблицы используются:
— справочник или документ;
— регистр сведений;
— регистр накопления;
— виртуальные таблицы, например СрезПоследних, Остатки, Обороты.
4. Настройки списка:
— указана ли основная таблица;
— включено ли динамическое считывание данных;
— задан ли произвольный запрос;
— какие поля выбраны как ключевые.
5. Какие отборы и сортировки устанавливает пользователь.
6. Что именно медленно:
— открытие списка;
— установка отбора;
— сортировка;
— прокрутка;
— обновление списка.
7. Примерное количество записей в основных таблицах.
8. Если есть, замер через технологический журнал, SQL Server Profiler или консоль запросов.

Запрос 1С присылайте вместе с параметрами. Я проверю:

— условия соединения и использование индексов;
— лишние ЛЕВЫЕ СОЕДИНЕНИЯ;
— виртуальные таблицы и параметры периода;
— вложенные запросы и временные таблицы;
— условия ИЛИ, НЕ, ПОДСТРОКА;
— сортировки и вычисляемые поля;
— дублирование строк;
— возможность указать основную таблицу;
— уникальность ключевых полей динамического списка;
— необходимость динамического считывания;
— порядок пользовательских отборов.

Для динамического списка обычно применяются такие правила:

— основной таблицей лучше делать таблицу, которая однозначно идентифицирует строку, например Справочник.Номенклатура или Документ.РеализацияТоваровУслуг;
— для произвольного запроса желательно задать ключевые поля, иначе платформа может использовать номер строки, из-за чего при прокрутке и обновлении приходится заново обрабатывать начало выборки;
— поля соединения должны соответствовать индексам;
— часто отбираемые поля желательно индексировать;
— вычисляемые поля не следует использовать для сортировки;
— тяжелые условия лучше включать в текст запроса, а не оставлять пользовательским отбором;
— СрезПоследних следует ограничивать параметрами периода и отбором по измерениям;
— для сложного списка из нескольких таблиц динамическое считывание не всегда ускоряет работу, иногда его лучше отключить;
— в список не стоит выводить лишние поля и поля через несколько уровней точек.

Например, неудачная конструкция:

|ВЫБРАТЬ
| Номенклатура.Ссылка,
| Номенклатура.Наименование,
| ЕСТЬNULL(Цены.Цена, 0) КАК Цена
|ИЗ
| Справочник.Номенклатура КАК Номенклатура
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Дата) КАК Цены
| ПО Цены.Номенклатура = Номенклатура.Ссылка
|ГДЕ
| Номенклатура.Наименование ПОДОБНО &СтрокаПоиска

Проблемы здесь могут возникнуть из-за:

— поиска по Наименование через ПОДОБНО;
— большого количества строк в СрезПоследних;
— отсутствия отбора по виду цены или организации;
— дублирования строк при неуникальной записи регистра;
— сортировки по вычисляемому полю ЕСТЬNULL(Цены.Цена, 0).

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

|ВЫБРАТЬ
| Номенклатура.Ссылка,
| Номенклатура.Наименование,
| Цены.Цена
|ИЗ
| Справочник.Номенклатура КАК Номенклатура
| ЛЕВОЕ СОЕДИНЕНИЕ
| РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
| &Дата,
| ВидЦены = &ВидЦены
| И Организация = &Организация
| ) КАК Цены
| ПО Цены.Номенклатура = Номенклатура.Ссылка

Но окончательный вариант зависит от структуры регистра, измерений, ресурсов и реальных отборов. Вставьте сюда текущий запрос в исходном виде. Я верну оптимизированный вариант и отдельно укажу, какие настройки изменить в динамическом списке.

[Автор]

Записи