1С: как посмотреть SQL-запрос к базе данных

Платформа 1С не работает с SQL напрямую: разработчик пишет запрос на встроенном языке запросов, а платформа сама транслирует его в команды для СУБД — Microsoft SQL Server, PostgreSQL, Oracle или IBM Db2. Из-за этого «увидеть» итоговый SQL-запрос в коде конфигурации невозможно — он формируется в момент выполнения и зависит от типа СУБД, версии платформы и структуры данных.

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

Как 1С формирует SQL и почему запрос нельзя увидеть в коде

Запрос на языке 1С — это абстракция. Конструкция вида ВЫБРАТЬ Номенклатура.Ссылка ИЗ Справочник.Номенклатура превращается платформой в обращение к физическим таблицам с именами вроде _Reference123, с учётом соединений с таблицами табличных частей, итогов и разделителей данных. Один логический объект может соответствовать нескольким физическим таблицам.

Трансляция выполняется на стороне сервера 1С в момент выполнения метода Выполнить() или Выгрузить(). На текст запроса влияют: тип СУБД, настройки совместимости, режим разделения данных, права пользователя (ограничение доступа на уровне записей добавляет в SQL дополнительные условия). Поэтому один и тот же запрос 1С в разных базах может порождать разный SQL.

Просмотр SQL-запроса через технологический журнал

Технологический журнал — основной штатный способ увидеть, что именно платформа отправляет в СУБД. Для включения нужно создать файл logcfg.xml в каталоге конфигурации технологического журнала (обычно conf рядом с исполняемыми файлами платформы на сервере) и перезапустить службу агента сервера 1С.

Для протоколирования запросов к MS SQL Server используется событие DBMSSQL, для PostgreSQL — DBPOSTGRS, для Oracle — DBORACLE, для Db2 — DBDB2. Дополнительно стоит включить событие DBV8DBENG для файловых баз и события блокировок (TLOCK, TDEADLOCK) при диагностике взаимоблокировок.

<config xmlns="http://v8.1c.ru/v8/tech-log"><log location="C:\1c_logs" history="24"><event><eq property="name" value="DBMSSQL"/></event><property name="sql"/></log></config>

В примере журнал пишется в каталог C:\1c_logs с хранением 24 часа, фиксируются события DBMSSQL и текст самого SQL в свойстве sql. После воспроизведения операции в 1С откройте файлы журнала и найдите нужное событие по времени или по имени пользователя — рядом с ним будет полный текст SQL-запроса с параметрами.

1. 1
   Создайте каталог для логов и убедитесь, что у службы сервера 1С есть права на запись
2. 2
   Разместите logcfg.xml с событием DBMSSQL (или соответствующим вашей СУБД) в каталоге conf платформы
3. 3
   Перезапустите службу агента сервера 1С
4. 4
   Воспроизведите проблемную операцию в 1С
5. 5
   Откройте файлы журнала и найдите событие по времени, пользователю или процессу
6. 6
   Скопируйте текст SQL и проанализируйте его в среде СУБД
7. 7
   После диагностики отключите журнал или сократите состав событий

Просмотр запросов средствами самой СУБД

Альтернатива техножурналу — наблюдение за запросами на стороне СУБД. В Microsoft SQL Server для этого служат Extended Events (рекомендуемый способ) или устаревший SQL Server Profiler. В трассировке запросы от 1С видны с именем приложения и хоста сервера 1С, что позволяет отфильтровать их от других подключений.

В PostgreSQL помогает параметр log_statement и расширение pg_stat_statements, которое собирает статистику по всем выполняемым запросам: время, количество вызовов, чтение буферов. Это удобно для поиска самых тяжёлых запросов в целом, а не конкретного экземпляра.

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

Консоль запросов и отладчик: что они показывают

Консоль запросов (штатная в управляемых формах некоторых типовых конфигураций или внешние обработки) позволяет выполнить запрос на языке 1С, посмотреть результат и временные таблицы. Это удобно для проверки логики, но итоговый SQL консоль не показывает — она работает на уровне абстракции платформы.

В конфигураторе при отладке можно остановиться на строке Запрос.Выполнить() и просмотреть текст запроса, параметры и менеджер временных таблиц через «Вычислить выражение». Это помогает убедиться, что в запрос подставляются ожидаемые значения, прежде чем искать проблему на уровне СУБД.

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

Разбор результата: как читать полученный SQL

Текст из техножурнала выглядит непривычно: физические таблицы имеют технические имена, соединения многочисленны, условия размножены. Чтобы сориентироваться, сопоставляйте физические таблицы с объектами метаданных по структуре хранения базы — её можно посмотреть в конфигураторе через «Администрирование → Функции для технического специалиста» (в типовых) или получить методом ПолучитьСтруктуруХраненияБазыДанных().

Для анализа производительности скопируйте запрос в среду СУБД (SQL Server Management Studio, pgAdmin) и посмотрите план выполнения. Тревожные признаки: сканирование больших таблиц вместо поиска по индексу, вложенные циклы над миллионами строк, неявные преобразования типов в условиях. Часто причина — отсутствие индекса по полям соединения или выборка лишних полей и соединений «на всякий случай» в запросе 1С.

Типичные ошибки и ограничения

Частая ошибка — искать SQL в файловой базе через событие DBMSSQL: файловый вариант не использует клиент-серверную СУБД, и запросы к ней протоколируются событием DBV8DBENG. Вторая типичная ситуация — забыть перезапустить службу агента после изменения logcfg.xml, из-за чего журнал просто не пишется.

Ещё одна ловушка — попытка оптимизировать SQL напрямую. Индексы и структуру таблиц в базе 1С нельзя менять в обход платформы: при обновлении конфигурации реструктуризация может привести к конфликтам. Оптимизировать нужно запрос на языке 1С: убирать лишние соединения, использовать временные таблицы, индексировать поля условий.

Частые вопросы