Как посмотреть выемки в 1С: глубокий анализ и отладка

В процессе разработки и сопровождения конфигураций на платформе 1С:Предприятие разработчики часто сталкиваются с необходимостью понять, какие именно данные считываются из базы при выполнении той или иной операции. Понятие «выемка» не является официальным термином в документации фирмы «1С», однако в профессиональной среде под ним обычно подразумевают массив данных, извлекаемый запросом или выборкой из набора данных. Умение анализировать эти процессы критически важно для оптимизации производительности системы.

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

Существует несколько уровней анализа: от просмотра структуры запроса в конфигураторе до перехвата реальных SQL-команд на уровне СУБД. В этой статье мы рассмотрим методы, которые помогут вам заглянуть «под капот» механизма выборки данных и понять, что именно происходит в момент выполнения кода.

Понятие выемки данных в архитектуре 1С

Прежде чем приступать к техническим деталям, необходимо четко определить, что мы понимаем под выемкой. В контексте платформы 1С это результат выполнения запроса к информационной базе, который попадает в объект типа ВыборкаИзРезультатаЗапроса или передается в табличный документ. Ошибки на этом этапе часто приводят к тому, что система читает миллионы строк, хотя для работы требуется лишь десяток.

Механизм выборки данных тесно связан с индексами и планами выполнения, которые строит сервер баз данных. Если разработчик не учитывает особенности индексации при написании кода, производительность системы может упасть катастрофически.

⚠️ Внимание: Термин «выемка» является сленговым. В официальной документации ищите разделы, посвященные объектам «Запрос», «НаборДанных» и механизмам работы с выборками.

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

Анализ запросов через Консоль запросов

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

Для начала работы необходимо открыть обработку и ввести текст запроса на встроенном языке 1С. После выполнения вы увидите результат в табличной части. Однако главная ценность инструмента скрыта в кнопке «Показать текст запроса на языке СУБД». Нажав её, вы получите точную копию команды, которая ушла в сервер баз данных.

• 🔍 Позволяет увидеть реальный SQL-код, генерируемый платформой.
• ⚡ Дает возможность проверить работу индексов через план выполнения.
• 📊 Помогает визуально оценить объем выбираемых данных перед внедрением в код.

Использование консоли запросов требует понимания синтаксиса языка запросов 1С. Ошибки в написании условий отбора могут привести к полному сканированию таблиц (Full Table Scan), что является главной причиной тормозов. Проверяйте, используются ли поля, по которым построены индексы, в условиях соединения и отбора.

Использование технологического журнала (ТЖ) для трассировки

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

Настройка ТЖ производится через файл logcfg.xml, расположенный в каталоге платформы. Для анализа выемок необходимо включить события, связанные с выполнением запросов. Обычно это события типа DBMSSQL (для MS SQL) или DBPostgreSQL, а также событие CALL для отслеживания вызовов методов.

<log>
<event>
<eq property="Name" value="DBMSSQL"/>
<property name="Sql"/>
<property name="Duration"/>
</event>
</log>

После включения логирования и воспроизведения проблемы на клиенте, вы получите файлы логов, содержащие подробную информацию о каждом обращении к базе. Анализируя эти данные, можно найти запросы с наибольшим временем выполнения (Duration) и изучить их структуру. Это позволяет найти скрытые проблемы, которые не видны при обычном тестировании.

⚠️ Внимание: Включение подробного логирования всех запросов на рабочей базе может привести к переполнению диска и снижению производительности из-за записи логов. Используйте фильтры по имени пользователя или длительности запроса.

Анализ логов ТЖ — задача трудоемкая, но единственно верная для поиска проблем в распределенных системах или при работе с большим количеством пользователей. Специальные утилиты, такие как CVAnaliz или скрипты на PowerShell, помогают агрегировать данные из тысяч строк логов и выделять самые тяжелые выемки.

Отладка выборки данных в Конфигураторе

Если у вас есть доступ к базе в режиме Конфигуратора, вы можете использовать встроенный отладчик для пошагового анализа формирования выборки. Этот метод идеален для понимания логики работы конкретного участка кода, где создается объект ВыборкаДанных.

Установите точку останова (Breakpoint) на строке, где начинается цикл обхода выборки, например, Пока Выборка.Следующий() Цикл. Запустите отладку и дождитесь остановки. В окне «Выражения» или «Переменные» вы сможете раскрыть объект выборки и посмотреть текущие значения полей.

• 🛠 Позволяет видеть значение переменных в реальном времени.
• 🔄 Дает возможность пошагово пройти по каждой записи выборки.
• 🧩 Помогает понять, как меняются данные в процессе обработки.

Однако стоит помнить, что отладка в Конфигураторе работает в однопользовательском режиме и может искажать картину производительности. То, что быстро выполняется в отладчике на локальном компьютере, может тормозить на сервере под нагрузкой. Тем не менее, для проверки логики отборов этот метод незаменим.

Особенность отладки больших выборок

Если выборка содержит миллионы записей, пошаговая отладка займет огромное количество времени. В таких случаях используйте отладку с условием (Conditional Breakpoint), чтобы останавливаться только на конкретных записях.

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

Перехват SQL-команд на уровне СУБД

Наиболее точную картину того, какие данные выгружаются из базы, дают средства мониторинга самой системы управления базами данных (СУБД). Для MS SQL Server это SQL Server Profiler или Extended Events, для PostgreSQL — логирование медленных запросов или утилита pg_stat_statements.

Подключив профайлер к базе данных 1С, вы увидите поток команд в реальном времени. Команды 1С обычно обернуты в хранимые процедуры или представляют собой динамический SQL. Ключевым моментом здесь является анализ параметров, передаваемых в запрос, и времени их выполнения.

Инструмент	Для какой СУБД	Основное преимущество	Сложность настройки
SQL Server Profiler	MS SQL Server	Визуализация в реальном времени	Низкая
Extended Events	MS SQL Server	Минимальное влияние на сервер	Высокая
pg_stat_statements	PostgreSQL	Статистика по всем запросам	Средняя
Explain Plan	Любая	Показывает план выполнения	Средняя

Использование планов выполнения (Execution Plan) позволяет увидеть, какие индексы использует сервер. Если вы видите значок предупреждения или оператор «Clustered Index Scan» на большой таблице, это сигнал о том, что выемка данных происходит неоптимально. Возможно, отсутствует нужный индекс или условие запроса написано так, что сервер не может его использовать.

При анализе через СУБД важно обращать внимание на параметризированные запросы. Платформа 1С часто использует их для повторного использования планов выполнения. Однако иногда это приводит к проблеме «параметрического сноса» (parameter sniffing), когда план, построенный для одних значений параметров, оказывается неэффективным для других.

Оптимизация выборки и работа с временными таблицами

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

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

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

// Неоптимально: запрос внутри цикла
Для каждого Элемент из Справочник.Номенклатура Цикл
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ.. ГДЕ Номенклатура = &Номенклатура";
// Выполнение запроса..
КонецЦикла;

// Оптимально: одна выемка во временную таблицу
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ.. ПОМЕСТИТЬ ВТ_Данные";
Запрос.Выполнить();
// Дальнейшая работа с ВТ_Данные

⚠️ Внимание: Не злоупотребляйте временными таблицами. Создание слишком большого количества промежуточных таблиц может привести к росту потребления памяти и замедлению работы темпоральной базы данных (tempdb).

Также стоит обратить внимание на использование операторов РАЗРЕШЕННЫЕ и ТОЛЬКО в запросах. Явное указание полей, которые необходимы для дальнейшей работы, вместо использования * (звездочки), уменьшает объем передаваемых данных по сети и ускоряет формирование выборки.

Частые ошибки при формировании выборок

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

Другая ошибка — использование функций в условиях отбора, например, ГОД(Дата) = 2023. Такое условие делает невозможным использование индекса по полю Дата, так как серверу приходится вычислять функцию для каждой строки таблицы перед сравнением. Правильно писать диапазон дат: Дата >= '2023.01.01' И Дата < '2026.01.01'.

Не стоит забывать и о блокировках. При выборке данных для обновления (например, при проведении документов) важно правильно устанавливать блокировки, чтобы избежать взаимоблокировок (deadlocks) с другими пользователями. В 1С для этого используются ключевые слова ДЛЯ ИЗМЕНЕНИЯ и параметры изоляции транзакций.

Как посмотреть выемку конкретного документа в режиме предприятия?

В режиме предприятия напрямую посмотреть SQL-запрос нельзя. Необходимо использовать внешние обработки, такие как «Консоль запросов», подключенную к этой базе, или анализировать Технологический журнал, предварительно включив логирование событий SQL.

Почему выборка работает быстро в консоли запросов, но медленно в коде?

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

Что такое «сначала» и «потом» в запросах 1С?

Это специальные виртуальные таблицы для регистров накопления и сведений. Они позволяют получать остатки и обороты без сложных группировок. Использование этих таблиц часто оптимизирует выемку данных по регистрам.

Можно ли отменить долгий запрос на выемку данных?

Да, в режиме Предприятия можно нажать кнопку «Прервать» (красный квадрат) на панели инструментов. На уровне сервера 1С сессия будет завершена, а транзакция откатлена сервером СУБД.