Разработка отчетности на платформе 1С:Предприятие часто сталкивается с необходимостью глубокой оптимизации. Когда стандартный отчет начинает тормозить, первым шагом специалиста становится анализ того, какой именно SQL-запрос уходит в базу данных. Система компоновки данных (СКД) генерирует код автоматически, скрывая его от глаз пользователя, что создает трудности при диагностике узких мест производительности.
Понимание того, как извлечь этот скрытый код, критически важно для любого разработчика. Без доступа к «сырому» тексту запроса невозможно провести корректный анализ плана выполнения или найти отсутствующие индексы. Существует несколько проверенных способов получить эту информацию, от использования встроенных инструментов отладки до прямого анализа метаданных в конфигураторе.
В этой статье мы подробно разберем все актуальные методы перехвата запросов. Вы узнаете, как работать с лаконичными запросами, как читать сгенерированный код макета и какие настройки трассировки помогут увидеть реальную картину взаимодействия с СУБД. Эти знания позволят вам превратить медленные отчеты в высокопроизводительные инструменты аналитики.
Использование внешнего обработчика отладки запросов
Самым надежным и наглядным способом получить текст запроса является использование специализированных внешних обработчиков. Такие инструменты, как «Анализ производительности» или «Консоль запросов», подключаются к работающей базе и перехватывают все обращения к серверу баз данных в реальном времени. Это позволяет увидеть не только сам текст, но и время его выполнения.
Для начала работы необходимо запустить обработчик отладки в отдельном окне. Затем в режиме предприятия откройте нужный отчет, построенный на СКД. В момент формирования отчета в окне отладчика появится список выполненных команд. Вам нужно найти запрос с типом СКД или содержащий специфические временные таблицы, характерные для системы компоновки.
Обратите внимание, что в окне отладчика часто отображается уже оптимизированный вариант запроса. Платформа может объединять несколько логических выборок в одну физическую команду для снижения сетевых издержек. Если вы видите сложный текст с множеством вложенных подзапросов, это нормальное поведение оптимизатора платформы.
⚠️ Внимание: Использование тяжелых обработчиков отладки на продуктивной базе с большим количеством пользователей может вызвать существенное замедление работы сервера. Проводите подобные замеры в тестовом окружении или в часы минимальной нагрузки.
После перехвата вы можете скопировать текст запроса прямо из интерфейса обработчика. Большинство современных утилит позволяют экспортировать полученный SQL-код в файл или сразу отправить его в консоль для дальнейшего анализа плана выполнения. Это дает возможность работать с запросом изолированно от интерфейса отчета.
Получение запроса через объект макета в коде
Если у вас есть доступ к исходному коду конфигурации или внешней обработки, вы можете получить текст запроса программно. Объект макета системы компоновки данных обладает методом ПолучитьТекстЗапроса(), который возвращает строку с готовым к выполнению кодом. Этот метод идеален для ситуативной отладки прямо в коде обработки.
Для реализации этого подхода необходимо получить ссылку на объект макета отчета. Обычно это делается через свойство Макет объекта отчета СКД. После вызова метода вы получите текст запроса, который можно вывести в сообщение пользователю или записать в лог. Пример реализации выглядит следующим образом:
Макет = Отчет.Макет;
ТекстЗапроса = Макет.ПолучитьТекстЗапроса();
Сообщить(ТекстЗапроса);
Важно понимать, что данный метод возвращает запрос с учетом текущих параметров отчета. Если вы измените дату начала периода или конкретный отбор в форме, текст запроса также изменится. Это позволяет анализировать влияние конкретных фильтров на сложность генерируемого SQL-кода.
Используйте метод ПолучениеТекстЗапроса() внутри цикла по различным вариантам отборов, чтобы автоматически собрать библиотеку тяжелых запросов для последующей оптимизации.
Однако стоит помнить о нюансах работы с временными таблицами. В некоторых случаях, особенно при использовании сложных вычислений внутри СКД, платформа разбивает логику на несколько последовательных запросов. Метод макета может вернуть только основную часть выборки, опуская служебные этапы создания промежуточных данных.
Анализ лаконичных запросов в конфигураторе
Основой любого отчета СКД является схема компоновки данных, которая хранится в виде XML или бинарного представления в метаданных. Внутри схемы содержится так называемый лаконичный запрос. Это упрощенное представление выборки, написанное на языке запросов 1С, которое платформа в дальнейшем транслирует в нативный SQL.
Чтобы увидеть этот текст, откройте конфигурацию в режиме Конфигуратор. Найдите нужный отчет в дереве метаданных и перейдите на вкладку Наборы данных. В нижней части окна вы увидите редактор запроса. Именно здесь хранится логика выборки, независимая от конкретных значений параметров, подставляемых при запуске.
Лаконичный запрос отличается от итогового SQL-кода отсутствием многих служебных конструкций. Здесь вы не увидите явного создания временных таблиц или сложных объединений, если они не описаны явно разработчиком. Платформа сама достраивает необходимую обвязку в момент исполнения.
| Элемент схемы | Влияние на запрос | Сложность анализа |
|---|---|---|
| Набор данных | Основной текст выборки | Низкая |
| Параметры | Подставляются в WHERE | Средняя |
| Вычисляемые поля | Добавляются в SELECT | Высокая |
| Отборы | Формируют условия фильтрации | Средняя |
Анализ лаконичного запроса полезен на этапе проектирования. Если вы видите здесь некорректные соединения таблиц или отсутствие необходимых полей для индексации, проблему можно решить до написания кода. Исправление ошибок на этом этапе экономит часы отладки в будущем.
Почему лаконичный запрос не совпадает с SQL?
Платформа 1С выполняет собственную оптимизацию. Она может менять порядок соединений таблиц, заменять подзапросы на джоины и объединять выборки, чтобы минимизировать количество обращений к СУБД. Поэтому прямой перевод лаконичного запроса в SQL "в уме" часто невозможен.
Извлечение запроса из сохраненного варианта отчета
Часто возникает ситуация, когда отчет работает медленно у пользователя, но у разработчика в тестовой базе все летает. В таких случаях необходимо получить точный текст запроса, который формируется с конкретными настройками пользователя. Для этого можно использовать механизм сохраненных вариантов отчетов.
Попросите пользователя сохранить текущие настройки отчета как новый вариант. Этот вариант можно выгрузить в файл mxl или передать разработчику в виде объекта метаданных. Загрузив этот вариант в конфигураторе или специальной обработке, вы увидите точную структуру отчета, включая все установленные отборы и группировки.
После загрузки варианта откройте его настройки и перейдите к просмотру запроса. Система сгенерирует текст запроса именно так, как он будет выполнен при запуске с этими настройками. Это позволяет воспроизвести проблему производительности локально, не подключаясь к рабочей базе пользователя.
Такой подход особенно эффективен при отладке отчетов с динамическими списками или сложными пользовательскими фильтрами. Вы получаете «слепок» состояния системы в момент возникновения ошибки, что значительно упрощает поиск причин тормозов.
⚠️ Внимание: Структура сохраненных вариантов может отличаться в разных версиях платформы 1С. При переносе варианта отчета между конфигурациями разных релизов возможна потеря части настроек или некорректная генерация запроса. Всегда проверяйте актуальность данных после импорта.
Использование технологического журнала для глубокого анализа
Для случаев, когда требуется максимальная детализация, используется технологический журнал (ТЖ) сервера 1С. Это мощный инструмент администрирования, который логирует низкоуровневые события работы сервера приложений. С его помощью можно получить не просто текст запроса, но и время его подготовки и выполнения на стороне СУБД.
Для включения логирования запросов необходимо отредактировать файл настроек logcfg.xml на сервере. Вам нужно добавить правило для события DBMSSQL (или другого используемого СУБД) с уровнем детализации, включающим текст запроса. После перезагрузки службы сервера все запросы начнут записываться в файлы журнала.
<event>
<eq property="name" value="DBMSSQL"/>
<property name="ospid" value="*"/>
<property name="pcode" value="*"/>
<property name="sql" value="*"/>
</event>
Анализ файлов ТЖ требует специального софта, так как объем данных может быть огромным. Существуют утилиты-парсеры, которые фильтруют логи по имени отчета или пользователя и выводят статистику. Вы сможете увидеть самые тяжелые запросы, их частоту выполнения и длительность блокировок.
Технологический журнал — это инструмент "последней мили". Используйте его только тогда, когда другие методы не позволили выявить причину проблем, так как он создает высокую нагрузку на дисковую подсистему сервера.
Важно своевременно отключать подробное логирование после завершения диагностики. Постоянная запись полных текстов SQL-запросов может быстро заполнить все доступное место на диске и замедлить работу сервера из-за интенсивных операций ввода-вывода.
Обработка специфических случаев и временных таблиц
При анализе запросов СКД разработчики часто сталкиваются с ситуацией, когда итоговый SQL-код выглядит запутанным из-за обилия временных таблиц. Платформа использует их для кэширования промежуточных результатов вычислений, особенно при работе с итогами и группировками.
Понимание структуры этих временных таблиц ключевое для оптимизации. Часто бывает так, что основной запрос выполняется быстро, но время тратится на заполнение или чтение временной таблицы, в которой миллионы строк. В тексте запроса такие таблицы обычно имеют имена вида #ВТ_ИмяТаблицы.
- 🔍 Проверяйте наличие индексов на временных таблицах, если они используются многократно.
- 📉 Анализируйте план выполнения для этапов вставки данных во временные таблицы.
- ⚙️ Попробуйте отключить использование временных таблиц в настройках СКД, если отчет позволяет.
В некоторых случаях можно упростить запрос, изменив настройки схемы компоновки. Например, отказ от использования некоторых видов вычислений внутри СКД в пользу вычислений на уровне запроса может убрать необходимость в создании лишних промежуточных структур данных.
☑️ Чек-лист анализа временных таблиц
Если вы видите, что временная таблица создается, но данные в нее не выбираются или выбираются не полностью, это явный признак неоптимальной настройки отчета. В таких случаях стоит пересмотреть структуру макета и убрать лишние ресурсы или измерения, которые не используются в итоговой форме.
Можно ли получить текст запроса без прав администратора?
Да, если у вас есть доступ к конфигуратору с правами на чтение метаданных, вы можете увидеть лаконичный запрос. Также некоторые внешние обработки для анализа производительности работают в режиме предприятия и не требуют прав администратора БД, однако их функционал может быть ограничен по сравнению с серверными логами.
Почему текст запроса в отладчике отличается от лаконичного?
Лаконичный запрос — это шаблон. В момент исполнения платформа подставляет значения параметров, раскрывает виртуальные таблицы (например, регистры накопления) и применяет оптимизации. Поэтому итоговый SQL всегда сложнее и объемнее исходного текста в конфигураторе.
Как оптимизировать запрос, если он слишком большой?
Большие запросы часто возникают из-за избыточных соединений или вычислений. Попробуйте разбить отчет на несколько частей, использовать отборы на уровне наборов данных для уменьшения выборки и проверить актуальность статистики по таблицам базы данных.