Как увидеть и отладить выборки данных в 1С 8.3

Отчёт строится пять минут, а должен — две секунды. Или в выборку попадают лишние строки, и цифры не сходятся. Чтобы это починить, нужно увидеть выемку данных — то, что платформа реально читает из базы. Для анализа и отладки выборок в 1С 8.3 есть четыре рабочих инструмента: консоль запросов (быстро посмотреть результат), технологический журнал (поймать, какой SQL ушёл в СУБД), отладчик в Конфигураторе (разобрать выборку по шагам) и трассировка на уровне сервера базы данных.

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

Что происходит, когда 1С читает данные из базы

Прикладной код на языке 1С не обращается к таблицам СУБД напрямую. Между ними — платформа. Объект Запрос на встроенном языке платформа переводит в SQL, отправляет в СУБД (MS SQL Server или PostgreSQL), получает строки и упаковывает их в РезультатЗапроса.

Поэтому «выемка данных» живёт сразу на трёх уровнях, и смотреть её можно на любом:

• 🧩 Язык запросов 1С — то, что написал разработчик: текст на русскоязычном синтаксисе ВЫБРАТЬ … ИЗ … ГДЕ.
• ⚙️ SQL в СУБД — во что платформа этот текст превратила. Имена таблиц тут служебные: _Reference123, _Document456.
• 🗄️ План выполнения — как сервер базы данных физически достаёт строки: по индексу или полным сканированием.

Медленная или неверная выборка почти всегда объясняется на одном из этих уровней. Задача — выбрать инструмент, который показывает нужный уровень, и не тратить время на остальные.

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

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

Где взять обработку:

1. В типовых конфигурациях на БСП консоль часто встроена: Функции для технического специалиста (режим открывается через меню сервиса) → раздел с инструментами разработчика.
2. Отдельную обработку «Консоль запросов» можно загрузить файлом: Файл → Открыть и указать .epf.

Что даёт консоль на практике:

• 📝 проверить текст запроса перед тем, как вставлять его в модуль;
• 🔢 подставить разные параметры и сравнить выборки;
• 📊 увидеть пустой результат там, где ждали строки, — и сразу понять, что условие ГДЕ отсекает лишнее;
• 🧱 посмотреть, как отрабатывают временные таблицы в пакетном запросе.

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

Технологический журнал: поймать реальный SQL

Когда тормозит отчёт или проведение, а код большой, искать проблему на уровне языка 1С бессмысленно. Нужен технологический журнал (ТЖ) — он пишет события платформы, включая каждый SQL-запрос к СУБД с длительностью.

ТЖ настраивается файлом logcfg.xml, который кладут в каталог conf установленной платформы. Вот конфигурация, которая ловит только запросы дольше одной секунды и пишет все их свойства:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\v8log" history="24">
    <event>
      <eq property="name" value="DBMSSQL"/>
      <ge property="durationus" value="1000000"/>
    </event>
    <property name="all"/>
  </log>
</config>

Разберём ключевые места:

• location — каталог, куда пишутся логи. Он должен существовать и иметь место на диске.
• history="24" — хранить логи 24 часа.
• Событие DBMSSQL — обращение к СУБД. durationus — длительность в микросекундах, 1000000 = 1 секунда.
• <property name="all"/> — выгрузить все свойства, в том числе Sql (текст запроса) и Context (где в коде он вызван).

Файл читается платформой автоматически, перезапуск служб не нужен. В каталоге появятся подпапки процессов с текстовыми файлами по дате и времени. В них ищите самые долгие события — у каждого будет строка Sql=… и Context=…, которая приводит прямо к проблемному месту.

Полезные события, кроме DBMSSQL:

💡 Чтобы в ТЖ попадал ещё и план выполнения, добавьте в событие свойство planSQLText — платформа запишет план вместе с текстом запроса, и отдельная трассировка СУБД не понадобится.

Отладчик в Конфигураторе: разобрать выборку по шагам

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

Порядок в Конфигураторе 8.3:

1. Включите отладку: меню Отладка → Начать отладку (или запустите 1С:Предприятие из Конфигуратора с включённой отладкой).
2. Поставьте точку останова на строке после Результат = Запрос.Выполнить(); — клик по левому полю строки или клавиша F9.
3. Повторите действие в пользовательском режиме, которое запускает этот код. Выполнение остановится на точке.
4. Выделите переменную Результат, нажмите Shift+F9 («Вычислить выражение»).
5. В открывшемся окне раскройте значение. Для таблицы вызовите Результат.Выгрузить() — увидите все строки и колонки выборки.

Через «Вычислить выражение» можно проверять и промежуточные значения: что лежит в параметре запроса, пустая ли ссылка, какой период передан. Это снимает половину вопросов «почему выборка пустая».

Рядом живёт ещё один инструмент — Отладка → Замер производительности. Он показывает, сколько времени заняла каждая строка кода и сколько раз она вызвана. Строка с запросом, у которой тысячи вызовов, — это почти наверняка запрос в цикле (о нём ниже).

Трассировка SQL на стороне СУБД

Когда известно, что медленный SQL-запрос есть, но нужно разобраться в его плане и нагрузке, спускайтесь на уровень сервера базы данных. Инструмент зависит от СУБД.

MS SQL Server. Классический способ — SQL Server Profiler: запускаете трассу, фильтруете по имени базы, ловите долгие RPC:Completed и SQL:BatchCompleted. Microsoft считает Profiler устаревшим и рекомендует Extended Events (XEvents) — тот же сбор событий с меньшей нагрузкой. План выполнения смотрят в SQL Server Management Studio: выполнить запрос с «Include Actual Execution Plan» или получить оценочный план.

PostgreSQL. Трассировки в духе Profiler тут нет, работают через конфигурацию:

• log_min_duration_statement в postgresql.conf — писать в лог все запросы дольше заданного порога (например, 1000 — одна секунда).
• модуль auto_explain — автоматически логировать план выполнения долгих запросов.
• расширение pg_stat_statements — накопительная статистика по запросам: сколько раз вызван, суммарное и среднее время.

В плане выполнения ищите главное: обращение к таблице идёт по индексу (Index Seek, Index Scan) или полным перебором (Table Scan, Seq Scan). Полное сканирование большой таблицы — первый кандидат на оптимизацию.

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

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

• 🧊 Временные таблицы вместо вложенных подзапросов. Оператор ПОМЕСТИТЬ ИмяТаблицы в пакетном запросе материализует промежуточный результат. Соединять с временной таблицей дешевле, чем с подзапросом, который СУБД пересчитывает.
• 🔑 Индексирование временных таблиц. Если по временной таблице идёт соединение или отбор, добавьте ИНДЕКСИРОВАТЬ ПО по полям соединения — иначе сервер перебирает её целиком.
• 🎯 Параметры виртуальных таблиц. У виртуальных таблиц регистров (Остатки, ОстаткиИОбороты) отбор задавайте в параметрах самой виртуальной таблицы, а не в ГДЕ после выборки. Платформа подставит отбор внутрь и прочитает меньше данных.
• 📉 Выбирайте только нужные поля. ВЫБРАТЬ * и лишние колонки раздувают выборку и мешают серверу использовать покрывающие индексы.
• 🚫 Никаких запросов в цикле. Самая частая причина, когда отчёт «вдруг» стал тормозить на больших данных.

Короткий чек-лист перед тем, как считать запрос оптимизированным:

После каждой правки снимайте SQL и план заново — иначе непонятно, стало лучше или нет.

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

Ошибки повторяются от базы к базе. Разложим симптомы и причины — так быстрее опознать свою.

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

Если ничего не помогло

Бывает, что запрос оптимизирован, а тормозит всё равно. Тогда проблема шире отдельной выборки:

• Устаревшая статистика СУБД или фрагментированные индексы — нужно регламентное обслуживание базы (обновление статистики, реиндексация).
• Блокировки: запрос ждёт, пока другой сеанс освободит данные. Смотрите события TLOCK и TTIMEOUT в технологическом журнале.
• Нехватка памяти или дисковый ввод-вывод на сервере СУБД — это уже вопрос к администратору и мониторингу сервера, а не к тексту запроса.

Если самостоятельно упёрлись в потолок, собирайте пакет для анализа: текст запроса, его SQL из ТЖ, план выполнения и замер производительности. С этими данными проблему решают на порядок быстрее, чем по описанию «всё тормозит».

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