Как оптимизировать запрос к остаткам для 1С:Фреш, чтобы пройти проверку на эффективность?

← На главную

При работе в облачных сервисах, таких как 1С:Фреш, к производительности дополнительного кода предъявляются жесткие требования. Если ваш отчет или обработка содержат неоптимальные запросы, система может вернуть их на доработку из-за чрезмерной нагрузки. Разберем, как привести запрос к стандартам быстродействия и правильно организовать работу с данными.

Почему возникают проблемы с производительностью?

Чаще всего претензии к запросам возникают по следующим причинам:

Соединение виртуальных таблиц: Прямое соединение двух виртуальных таблиц (например, Остатки и СрезПоследних) заставляет сервер выполнять тяжелые вычисления для каждой строки.
Отсутствие фильтрации в параметрах: Если условия отбора (например, по Организация или ТипРасчетов) стоят в секции ГДЕ, а не в параметрах виртуальной таблицы, система сначала выберет все данные из базы, а только потом отфильтрует их, что крайне неэффективно.
Составные типы данных: Обращение к полю Документ, который является составным типом, заставляет платформу строить сложные планы запроса, затрагивая множество таблиц базы данных.
Избыточные вычисления: Множественные конструкции ВЫБОР КОГДА внутри запроса замедляют выполнение и затрудняют чтение кода.

Шаг 1. Перенос условий в параметры виртуальных таблиц

Первое, что мы должны сделать — это максимально сузить выборку на этапе обращения к виртуальной таблице. Не полагайтесь на секцию ГДЕ для фильтрации основных измерений.

Рассмотрим пример. Если вам нужны остатки только по конкретным условиям, передавайте их в параметры таблицы Остатки:


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

Шаг 2. Использование временных таблиц вместо прямых соединений

Вместо того чтобы соединять виртуальную таблицу с другой, мы сначала выгружаем результат первой выборки во временную таблицу. Это позволяет СУБД построить индекс по нужному полю (например, Документ), что ускоряет последующее соединение в разы.

Порядок действий:

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

Шаг 3. Избавление от сложных конструкций в секции ВЫБРАТЬ

Если в вашем коде используется сложная логика ВЫБОР КОГДА для расчета интервалов просрочки или дат, попробуйте вынести вычисления во второй или третий пакет запроса. Первый пакет должен заниматься только подготовкой \"чистых\" данных. Работа с готовыми полями временной таблицы работает быстрее, чем вычисление значений "на лету" при соединении с виртуальными таблицами.

Шаг 4. Оптимизация обращения к документам

Если вам нужно получить дату документа или его реквизиты, не делайте это через обращение к полям составного типа внутри основного запроса (например, Документ.Дата). Это провоцирует скрытые соединения. Лучше использовать временную таблицу, в которую вы поместите только необходимые поля, либо сделать отдельный пакет, который соединяется с конкретной таблицей документа, если тип документа заранее известен.

Чек-лист по оптимизации для Фреш:

Проверьте, вынесены ли все возможные фильтры в параметры виртуальных таблиц (&Период, Условие).
Убедитесь, что временные таблицы проиндексированы по полям соединения (ИНДЕКСИРОВАТЬ ПО).
Исключите РАЗНОСТЬДАТ из секции ГДЕ, заменив её на прямое сравнение дат, если это возможно.
Разбейте сложный запрос на несколько пакетов, чтобы промежуточные результаты сохранялись во временных таблицах.
Избегайте обращения к полям через точку у составных типов в секции выбора.

Следование этим простым правилам позволит значительно снизить нагрузку на компоненты сервиса 1С:Фреш и сделает ваш отчет стабильным и быстрым.