Отчеты и Аналитика · 12 мин
Как оптимизировать отчет 1С и ускорить его формирование
Практические способы ускорить отчеты в 1С: настройка СКД, индексы, временные таблицы, отборы и типичные ошибки, из-за которых отчет формируется медленно.
Медленный отчет в 1С — почти всегда следствие конкретных и устранимых причин: неоптимального запроса, отсутствия индексов, избыточного объема выбираемых данных или неудачных настроек СКД. Прежде чем менять код или обращаться за доработкой, нужно локализовать проблему: понять, где именно теряется время — на выполнении запроса к базе, на компоновке данных или на выводе результата.
Оптимизация отчета начинается с замера. В конфигураторе есть инструмент «Замер производительности» (Отладка → Замер производительности), который показывает, какие строки кода и запросы занимают больше всего времени. Без замера любые правки — это гадание: часто оказывается, что тормозит не сам запрос, а, например, обработка результата в цикле или вывод тысяч строк в табличный документ.
Ниже разобраны рабочие приемы: от простых настроек, доступных пользователю без прав разработчика, до оптимизации запросов и схемы компоновки данных, которые выполняет программист. Порядок разделов соответствует логике поиска проблемы — от простого к сложному.
Как найти причину медленной работы отчета
Первый шаг — воспроизвести проблему с замером. Откройте конфигуратор, запустите отладку, включите замер производительности и сформируйте отчет с теми же параметрами, при которых он тормозит у пользователей. В результатах замера смотрите колонки «Время» и «Количество»: одна тяжелая строка указывает на конкретный запрос или процедуру.
Разделите проблему на три зоны. Если время уходит на запрос — работайте с текстом запроса и индексами. Если запрос выполняется быстро, но отчет все равно формируется долго — смотрите настройки СКД: группировки, ресурсы, вычисляемые поля. Если все быстро до момента вывода — проблема в объеме табличного документа: вывод сотен тысяч строк в табличный документ сам по себе медленный, и запрос тут ни при чем.
Полезный быстрый тест: сформируйте отчет за короткий период (день вместо года). Если время упало пропорционально — проблема в объеме данных и запросе. Если отчет медленный даже за один день — вероятны проблемы в структуре СКД, соединениях таблиц или отсутствии индексов.
Сделайте замер производительности и проверьте время выполнения запроса
Проверьте вычисляемые поля, группировки и число строк в результате
Сравните параметры отчета и проверьте ограничения доступа к данным
Оптимизация запроса: отборы, виртуальные таблицы, соединения
Главное правило: максимум фильтрации должен происходить на уровне запроса, а не после получения данных. Если параметры отчета (период, организация, склад) передаются в запрос как отборы виртуальной таблицы или условия ГДЕ, объем обрабатываемых данных сокращается на порядки. Если же запрос выбирает всё, а отбор накладывается в СКД на результат — база делает лишнюю работу.
При работе с регистрами используйте виртуальные таблицы (Остатки, Обороты, ОстаткиИОбороты) с явным указанием параметров: периодичности, условий отбора по измерениям. Виртуальная таблица без параметров заставляет СУБД строить выборку по всем данным регистра. Условия накладывайте в параметрах виртуальной таблицы, а не в секции ГДЕ — это позволяет платформе эффективнее построить запрос к СУБД.
Соединения таблиц — частый источник проблем. Избегайте соединений с подчиненными запросами без индексированных полей связи, не соединяйте виртуальные таблицы между собой без необходимости и не используйте левое соединение «на всякий случай», если данные можно получить одной выборкой. Также опасно применять функции к полям в условиях соединения и отбора (например, ПОДСТРОКА или НАЧАЛОПЕРИОДА к индексированному полю) — это отключает использование индекса.
Временные таблицы и пакетные запросы
Если отчет собирает данные из нескольких источников, разбейте один гигантский запрос на пакет: сначала отберите нужные данные во временную таблицу с индексированием ключевых полей, затем соединяйте ее с остальными выборками. Это уменьшает объем промежуточных данных и позволяет СУБД строить более эффективный план.
Команда ИНДЕКСИРОВАТЬ ПО в запросе временной таблицы критична: без индекса соединение с временной таблицей выполняется полным перебором. Индексируйте именно те поля, по которым идет соединение или отбор в последующих запросах пакета.
Не увлекайтесь: десятки временных таблиц с мелкими выборками тоже вредны — каждая создается и материализуется на сервере СУБД. Разумный ориентир: временная таблица оправдана, когда она отсекает значительную часть данных или используется в нескольких последующих запросах пакета.
ВЫБРАТЬ
Продажи.Номенклатура КАК Номенклатура,
СУММА(Продажи.КоличествоОборот) КАК Количество
ПОМЕСТИТЬ ВТ_Продажи
ИЗ
РегистрНакопления.Продажи.Обороты(&НачалоПериода, &КонецПериода, , Организация = &Организация) КАК Продажи
СГРУППИРОВАТЬ ПО
Продажи.Номенклатура
ИНДЕКСИРОВАТЬ ПО
НоменклатураИндексы: что проверить и когда добавлять
Отборы отчета работают быстро только тогда, когда по полям отбора существуют подходящие индексы. Для регистров платформа автоматически создает индексы по измерениям, но порядок измерений имеет значение: индекс эффективен, когда в отборе используются ведущие поля индекса. Если отчет фильтрует по измерению, которое стоит в структуре регистра последним, а первые измерения в отборе не участвуют, индекс может не использоваться.
Для типовых конфигураций менять порядок измерений — серьезное решение с последствиями для обновлений. Более безопасный путь: в параметрах виртуальной таблицы передавать отборы по всем ведущим измерениям, которые известны (например, организацию), либо строить запрос через временную таблицу с собственным индексом.
Признак проблемы с индексами — запрос, который на копии с малым объемом данных работает быстро, а в рабочей базе «ползет». План запроса на стороне СУБД (для MS SQL — через план выполнения, для PostgreSQL — EXPLAIN) покажет, используется ли индекс или выполняется полное сканирование таблицы.
Настройки СКД: что тормозит компоновку
Схема компоновки данных может замедлять отчет даже при быстром запросе. Типичные причины: вычисляемые поля со сложными выражениями, вызываемые для каждой строки; ресурсы с расчетом по иерархии; большое число детальных группировок; включенные по умолчанию общие итоги, которые пользователю не нужны.
Проверьте закладку «Настройки» варианта отчета: отключите общие итоги, если они не нужны; уберите из выбранных полей те, что не отображаются; замените выражения в вычисляемых полях на расчет в запросе, где это возможно, — агрегация на уровне СУБД почти всегда быстрее посчетных вычислений.
Отдельная тема — наборы данных типа «Объединение». Объединение нескольких запросов выполняется последовательно, и время складывается. Если объединение можно заменить одним запросом с группировкой, сделайте это. Также проверьте роли полей: корректно указанные роли (период, измерение, ресурс) помогают компоновщику строить оптимальный макет.
Ограничение объема данных и интерфейсные меры
Не все проблемы решаются кодом. Если пользователи формируют отчет за год по всем организациям, а смотрят только итоги, ограничьте объем на уровне настроек: сделайте период обязательным параметром, задайте значения по умолчанию (например, текущий месяц), вынесите детализацию до документа в отдельный вариант отчета.
Для тяжелых отчетов в клиент-серверном режиме полезно формирование в фоне: пользователь не ждет у «зависшего» окна, а получает результат по готовности. В управляемых формах это реализуется через длительные операции. Дополнительно рассмотрите регламентное предварительное формирование тяжелых отчетов ночью с сохранением результата — для аналитики за закрытые периоды это часто оптимальный вариант.
Если отчет выводит детальные данные, добавьте в настройки предупреждение о большом объеме или ограничение на максимальное число строк. Пользователь, который случайно запросил пять миллионов строк, должен получить понятное сообщение, а не зависший сеанс.
Как выбрать действие
Проверка результата оптимизации
Каждое изменение проверяйте повторным замером на тех же параметрах и на том же объеме данных. Сравнивайте не ощущения, а цифры: общее время формирования и время конкретного запроса. Оптимизация считается успешной, только если время сократилось на реальных данных рабочей базы (или ее полной копии).
Обязательно проверьте корректность результата: оптимизированный отчет должен выдавать те же итоги, что и исходный. Сверьте контрольные суммы по ключевым ресурсам за несколько периодов. Ускорение в десять раз бесполезно, если изменился смысл данных — это самая опасная ошибка при переписывании запросов.
После внедрения понаблюдайте за отчетом в эксплуатации: объемы данных растут, и запрос, оптимальный сегодня, через год может снова стать узким местом. Зафиксируйте время формирования типовых вариантов как ориентир для будущих проверок.
Как проверить результат
Заметно сократилось на реальных данных рабочей базы
Ускорение видно только на маленькой тестовой копии
Контрольные суммы по ресурсам совпадают
Итоги изменились — запрос переписан с ошибкой
Используются индексы (Index Seek / Index Scan)
Полное сканирование больших таблиц (Table Scan / Seq Scan)
Что важно запомнить
Оптимизация отчета начинается с замера, а не с правок. Основные резервы: отборы в параметрах запроса, индексы по полям отборов, временные таблицы с индексированием, чистка настроек СКД и ограничение объема выводимых данных. Любые изменения проверяйте на копии и сверяйте итоги с исходным отчетом.
Частые вопросы
Отчет тормозит только у одного пользователя, у остальных быстро. В чем причина?
Чаще всего дело в параметрах: пользователь формирует отчет за больший период или без отборов. Также проверьте ограничения доступа на уровне записей (RLS) — они добавляют в запрос дополнительные условия, которые могут радикально замедлить выполнение. Сравните замер под этим пользователем и под администратором с теми же параметрами.
Можно ли ускорить отчет без доступа к конфигуратору?
Частично да. Сократите период, задайте отборы по организации и складам, отключите в настройках лишние поля, группировки и общие итоги, используйте готовый вариант отчета вместо ручной настройки с нуля. Если этого недостаточно — нужна доработка запроса или СКД разработчиком.
Почему отчет на копии базы работает быстро, а в рабочей медленно?
Обычно из-за разницы в объеме данных, устаревшей статистики на СУБД или отличающихся индексов. Проверяйте оптимизацию на полной копии рабочей базы, а после внедрения обновите статистику по задействованным таблицам и сравните планы запросов.
Что лучше для тяжелого отчета: СКД или программное формирование?
СКД удобна настройками и расшифровкой, и в большинстве случаев ее достаточно при грамотном запросе. Программное формирование в табличный документ оправдано, когда нужен нестандартный алгоритм расчета или построчная обработка, не выразимая запросом. Но вывод сотен тысяч строк будет медленным в обоих вариантах — объем результата ограничивать придется в любом случае.
Опасно ли добавлять индексы в типовой конфигурации?
Добавление индекса через расширение или изменение конфигурации влияет на все операции записи в таблицу: каждый индекс замедляет запись и занимает место. Кроме того, изменения типовых объектов усложняют обновление. Перед добавлением индекса убедитесь замером, что проблема именно в его отсутствии, и оцените нагрузку на запись.
Как понять, что пора оптимизировать отчет, а не сервер?
Если медленно работает один конкретный отчет, а остальная система отзывчива — проблема в отчете. Если тормозят все отчеты и документы одновременно, смотрите на сервер: нехватку памяти, медленные диски, блокировки, устаревшую статистику СУБД. Замер производительности по конкретному отчету — самый быстрый способ разделить эти случаи.