Как ускорить выполнение часто повторяющихся запросов при проведении документа?

В процессе разработки часто возникает ситуация, когда при проведении документа с большим количеством строк система начинает работать медленно. Одной из самых частых причин является выполнение Запрос внутри цикла. Давайте разберем, почему это происходит и как правильно оптимизировать подобный код.

Разбор проблемы «Запросы в цикле»

Когда вы помещаете запрос в цикл, на каждой итерации происходит взаимодействие между сервером 1С и СУБД. Даже если один запрос выполняется всего 2–3 миллисекунды, при 700 итерациях общие накладные расходы на передачу управления становятся критическими. В результате общее время проведения документа увеличивается на несколько секунд, что крайне негативно сказывается на комфорте работы пользователей.

Отказ от запросов в цикле

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

Рассмотрим, как это реализовать на практике:

1. Создайте массив или СписокЗначений и заполните его всеми ключами аналитики при обходе строк документа.
2. Передайте полученный массив в Запрос в качестве параметра.
3. Используйте в запросе условие ГДЕ Аналитика.Ссылка В (&МассивКлючей).

Это позволит СУБД построить план выполнения для одной операции, что значительно быстрее, чем 700 последовательных поисков.

Работа с временными таблицами

Если объем данных велик или требуется выполнить сложные соединения, используйте МенеджерВременныхТаблиц. Это позволит эффективно обработать большие наборы данных за один проход по индексам. Последовательность действий будет следующей:

// Пример создания временной таблицы для ключей
Запрос = Новый Запрос;
Запрос.Текст = 
"ВЫБРАТЬ РАЗЛИЧНЫЕ
|	Т.Ключ КАК Ссылка
|ПОМЕСТИТЬ ВТ_Ключи
|ИЗ &ТаблицаКлючей КАК Т";
Запрос.УстановитьПараметр("ТаблицаКлючей", МассивКлючей);
Запрос.Выполнить();

После этого вы сможете выполнить соединение вашей временной таблицы с регистрами сведений, что обеспечит максимальную производительность.

Нюансы замера производительности

Важно помнить, что стандартный инструмент «Замер производительности» в Конфигураторе не всегда показывает полную картину. Давайте проанализируем, почему данные могут быть недостоверными:

• Не учитываются внутренние механизмы: Замер может не отображать время на запись движений в регистры или транзакционные операции, которые происходят уже после завершения основного кода проведения.
• Серверные вызовы: Если вы отлаживаете код на сервере, убедитесь, что настройки сервера позволяют корректно собирать статистику выполнения.
• Неточность ОС: Windows не является системой реального времени, поэтому микросекундные задержки могут варьироваться в зависимости от загрузки процессора.

Если вы подозреваете, что замер дает неполную картину, рекомендуем использовать ТехнологическийЖурнал или профилировщик СУБД. Эти инструменты покажут реальную нагрузку, возникающую при обращении к базе данных, включая время ожидания блокировок.

Проблема «Гигантомании» и составные типы

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

Подводя итог: не стремитесь к микро-оптимизации каждого отдельного запроса, если архитектура подразумевает сотни обращений к БД. Пересмотрите алгоритм проведения в целом, сократите количество записей в регистры и используйте пакетные запросы. Только комплексный подход позволит добиться высокой скорости работы системы.