Почему отчет на СКД выполняется медленнее, чем аналогичный запрос, и как оптимизировать его работу?

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

Разбор причин низкой производительности СКД

Когда вы программно вызываете ПроцессорВыводаРезультатаКомпоновкиДанныхВКоллекциюЗначений, система выполняет гораздо больше операций, чем при обычном Запрос.Выполнить(). Разберем основные причины «тормозов»:

1. Генерация макета: СКД преобразует настройки отчета в объектную модель. Если в схеме присутствуют сложные группировки, иерархические связи или вычисляемые поля, система совершает множество дополнительных итераций по данным.
2. Обработка ресурсов: Если поля, используемые в запросе, помечены в СКД как «Ресурсы», система будет пытаться пересчитывать их на каждом уровне группировки, что создает избыточную нагрузку на процессор.
3. Неоднородное время выполнения: Разница во времени (например, 40 минут против 9) часто связана с кэшированием планов запросов на стороне SQL-сервера и состоянием статистики СУБД. При первом запуске SQL-сервер тратит время на построение оптимального плана выполнения.

Анализ кода и оптимизация запросов

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

ВЫБРАТЬ
    ПродажиОбороты.Склад КАК Склад,
    ПродажиОбороты.Номенклатура КАК Номенклатура,
    СУММА(ПродажиОбороты.КоличествоОборот) КАК КоличествоОборот,
    СУММА(ПродажиОбороты.СтоимостьОборот) КАК СтоимостьОборот
ПОМЕСТИТЬ Продажи
ИЗ
    РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, Авто, ) КАК ПродажиОбороты
СГРУППИРОВАТЬ ПО
    ПродажиОбороты.Номенклатура, ПродажиОбороты.Склад
;

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

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

Рекомендации по ускорению работы отчетов

Для повышения скорости выполнения ваших отчетов рекомендуем придерживаться следующих правил:

1. Отключите автоматику СКД, если она не нужна. Если вы используете СКД только как инструмент получения данных, старайтесь упростить схему: удалите лишние группировки и условные оформления, которые могут замедлять процесс вывода.

2. Проверяйте планы запросов. Если время выполнения сильно разнится, используйте инструменты СУБД для анализа плана выполнения. Возможно, при определенных параметрах периода SQL Server выбирает неэффективный индекс, что приводит к полному сканированию таблиц.

3. Переходите на прямой запрос. Если вам не требуется динамическая настройка отчета пользователем, написание кода напрямую через объект Запрос всегда будет быстрее программной реализации через КомпоновщикМакета. Прямой запрос исключает этап компиляции метаданных СКД.

4. Оптимизируйте индексы. Убедитесь, что все поля, используемые в секции ПО при ЛЕВОМ СОЕДИНЕНИИ, проиндексированы в регистрах накопления. Это позволит СУБД объединять данные за доли секунды.

Используйте замеры производительности в конфигураторе для локализации узких мест. Помните, что команда ПроцессорВывода.Вывести(ПроцессорКомпоновкиДанных) является итоговой, и если замер показывает длительное время выполнения именно на ней, значит, основная проблема скрыта в сложности макета или избыточности группировок, заложенных в схеме.