Как ускорить СКД в 1С: практическое руководство

Медленный отчёт на системе компоновки данных (СКД) — одна из самых частых жалоб пользователей 1С. Отчёт, который формируется 5–10 минут, блокирует работу менеджеров, а на больших базах может вообще завершаться по таймауту. При этом причина почти всегда не в «тяжёлой платформе», а в конкретных ошибках структуры запроса и настроек схемы.

СКД — это генератор запросов: на основе вашей схемы и пользовательских настроек платформа строит итоговый SQL-запрос к СУБД. Если исходный запрос набора данных написан неоптимально, или в ресурсах используются сложные выражения, итоговый запрос становится громоздким, и СУБД выполняет его медленно. Хорошая новость: большинство проблем диагностируется и устраняется без переписывания отчёта с нуля.

Ниже разобраны основные причины медленной работы СКД и конкретные приёмы ускорения: от оптимизации запроса набора данных до настроек ресурсов, отборов и итогов. Порядок разделов соответствует логике поиска проблемы — от самого частого источника к более редким.

Как найти, что именно тормозит в отчёте

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

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

В клиент-серверном варианте полезно посмотреть план запроса средствами СУБД (MS SQL Server, PostgreSQL). Полное сканирование больших таблиц (Clustered Index Scan, Seq Scan) там, где ожидался поиск по индексу, — прямое указание на проблему с отборами или соединениями.

Оптимизация запроса набора данных

Запрос набора данных — главный источник проблем производительности СКД. Базовое правило: запрос должен возвращать только те данные, которые реально нужны отчёту, и делать это максимально эффективно для СУБД.

Типичные приёмы оптимизации:

• Отборы внутри запроса, а не в настройках. Условия в секции ГДЕ ограничивают выборку на уровне СУБД. Отбор, заданный только в настройках СКД, тоже попадает в итоговый запрос, но параметризованные условия в тексте запроса дают СУБД больше свободы для оптимизации и работают предсказуемее.
• Виртуальные таблицы с параметрами. При обращении к виртуальным таблицам регистров (Обороты, Остатки, СрезПоследних) всегда передавайте параметры: период, условия по измерениям. Вызов без параметров заставляет СУБД строить виртуальную таблицу по всем данным регистра.
• Меньше соединений. Каждое ЛЕВОЕ СОЕДИНЕНИЕ увеличивает стоимость запроса. Если данные нужны только для расшифровки, их лучше получать не соединением, а через параметризованные отчёты-детализации.
• Не выбирать лишние поля. Поля, которые не используются ни в настройках, ни в расчётах, всё равно читаются из базы и передаются в компоновщик.

Отдельная тема — соединение с виртуальными таблицами. Соединение двух виртуальных таблиц регистров (например, Остатки и Обороты) почти всегда медленнее, чем один запрос к одной виртуальной таблице с нужными параметрами. Если требуются данные нескольких регистров, рассмотрите объединение наборов данных в СКД вместо соединения в запросе.

Использование нескольких наборов данных вместо сложного запроса

СКД умеет связывать несколько наборов данных на уровне схемы: связи наборов данных на закладке «Связи наборов данных». Это позволяет заменить один тяжёлый запрос с множеством соединений на несколько простых запросов, каждый из которых СУБД выполнит быстро.

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

У этого подхода есть ограничение: связывание наборов происходит на сервере 1С, и при очень больших объёмах данных (сотни тысяч строк в каждом наборе) компоновка в памяти сама становится узким местом. Поэтому приём эффективен для агрегированных данных, но не для детальных выборок.

Ускорение за счёт настроек ресурсов и вычисляемых полей

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

Практические рекомендации:

• Переносите сложную логику вычислений из выражения ресурса в запрос набора данных: рассчитайте поле на уровне запроса, а в ресурсе оставьте простую Сумма(Поле).
• Вычисляемые поля с выражениями на языке выражений СКД рассчитываются на этапе компоновки, а не в СУБД. Если выражение можно выполнить в запросе — выполняйте в запросе, это почти всегда быстрее.
• Проверьте, не рассчитываются ли ресурсы по группировкам, которых нет в типовых настройках. Лишние группировки в списке «Рассчитывать по» увеличивают объём работы.

Особое внимание — итогам. Если отчёт не нуждается в общих итогах, отключите их в настройках (свойство группировки «Общие итоги»). Расчёт итогов по всем уровням группировок на больших выборках ощутимо нагружает и СУБД, и компоновщик.

1. 1
   Откройте отчёт в консоли СКД и получите итоговый запрос с типовыми настройками
2. 2
   Выполните запрос отдельно и замерьте время — определите, проблема в запросе или в компоновке
3. 3
   Если медленный запрос: добавьте параметры виртуальных таблиц, уберите лишние соединения и поля
4. 4
   Если медленная компоновка: упростите ресурсы, уберите лишние вычисляемые поля и группировки
5. 5
   Отключите общие итоги и лишние детализации, если они не нужны
6. 6
   Проверьте план запроса на СУБД и при необходимости обновите статистику и индексы
7. 7
   Замерьте результат на реальных данных и сравните с исходным временем

Отборы, параметры и работа с периодами

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

Проверьте, что даты из параметров отчёта реально передаются в параметры виртуальных таблиц и в условия запроса. Для стандартных отчётов на управляемых формах платформа часто делает это автоматически, но в самописных схемах связь параметров с запросом нужно контролировать вручную.

Ещё одна деталь: отборы по спискам значений. Условие «Номенклатура В (&СписокНоменклатуры)» с большим списком может выполняться медленно. Если список формируется программно и содержит тысячи элементов, лучше поместить его во временную таблицу и соединиться с ней, либо пересмотреть логику отбора (например, фильтровать по группе или свойству).

Оптимизация на уровне СУБД и инфраструктуры

Если запрос написан корректно, но всё равно выполняется медленно, проблема может быть на уровне базы данных. В клиент-серверной 1С актуальность статистики и состояние индексов напрямую влияют на скорость запросов, которые генерирует СКД.

Что стоит проверить администратору СУБД:

• регламентное обновление статистики и реиндексацию — устаревшая статистика приводит к выбору неоптимальных планов;
• наличие индексов по полям, используемым в отборах и соединениях (для типовых объектов индексы обычно созданы, но для добавленных реквизитов и измерений их может не быть);
• настройки СУБД: объём памяти, параллелизм, параметры tempdb — на больших базах неправильная конфигурация сервера сводит на нет любую оптимизацию запросов.

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

Проверка результата после оптимизации

После внесения изменений сравнивайте не только субъективное «стало быстрее», но и измеримые показатели: время выполнения запроса в консоли, время формирования отчёта целиком, объём возвращаемых строк. Замеры делайте на одинаковых настройках отчёта и сопоставимом объёме данных.

Важно проверить корректность: после переписывания запроса или переноса вычислений сверьте итоговые цифры отчёта с эталонными значениями (например, с данными за прошлый период или с независимым отчётом). Ускорение, достигнутое потерей части данных, — не ускорение, а ошибка.

Контрольные точки

Как проверить результат

Время выполнения запроса в консоли СКД

Норма

Заметно снизилось относительно исходного замера на тех же настройках

Тревожный признак

Не изменилось или выросло — оптимизация не сработала

План запроса на СУБД

Норма

Используются поиски по индексам, нет сканирования больших таблиц

Тревожный признак

Остались Seq Scan / Index Scan по крупным таблицам

Итоговые цифры отчёта

Норма

Совпадают с эталонными данными

Тревожный признак

Расхождения — ошибка в переписанном запросе

Время формирования у пользователя

Норма

Отчёт формируется в приемлемые для работы сроки

Тревожный признак

Запрос быстрый, но отчёт всё ещё медленный — копать компоновку и вывод

Частые вопросы об ускорении СКД

Почему отчёт быстро работает на тестовой базе, но медленно на рабочей?

Тестовая база обычно содержит в разы меньше данных, поэтому неоптимальный запрос там незаметен. На рабочей базе проявляются сканирования больших таблиц, нехватка индексов и устаревшая статистика. Оптимизацию всегда проверяйте на копии рабочей базы с реальным объёмом данных.

Что быстрее: один сложный запрос или несколько наборов данных со связями?

Зависит от объёма. Для агрегированных данных несколько простых наборов со связями часто быстрее, так как каждый запрос СУБД оптимизирует отдельно. Но если каждый набор возвращает сотни тысяч строк, связывание в памяти сервера 1С станет узким местом — тогда лучше один хорошо написанный запрос.

Помогает ли перенос отчёта в фоновое выполнение?

Фоновое выполнение не ускоряет отчёт, а лишь разблокирует интерфейс пользователя. Это приемлемый временный приём для тяжёлых отчётов, но саму причину медленной работы он не устраняет — оптимизировать запрос и настройки всё равно нужно.

Влияет ли условное оформление на скорость отчёта?

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

Нужно ли добавлять индексы под конкретный отчёт?

Иногда да, если отчёт фильтрует по неиндексированным реквизитам или измерениям. Но каждый дополнительный индекс замедляет запись в таблицу и занимает место. Решение принимайте по результатам анализа плана запроса и с учётом частоты записи в таблицу, а не «на всякий случай».

Как ускорить отчёт, который строится за большой период?

Ограничьте период по умолчанию разумным значением (месяц, квартал), используйте итоги регистров вместо расчёта по детальным записям, а для регулярных тяжёлых отчётов рассмотрите предварительное накопление агрегированных данных в отдельном регистре сведений или регистре накопления.