Как посмотреть план запроса в 1С

План запроса — это последовательность операций, которую СУБД выбирает для выполнения SQL-запроса: какие индексы использовать, в каком порядке соединять таблицы, сканировать таблицу целиком или искать по ключу. Когда отчёт в 1С формируется минутами или документ проводится подозрительно долго, именно план запроса показывает, где теряется время.

Сама платформа 1С не содержит встроенного просмотрщика планов: запросы на встроенном языке транслируются в SQL, и план нужно смотреть средствами СУБД — SQL Server Management Studio для MS SQL, pgAdmin или EXPLAIN для PostgreSQL. Задача администратора — сначала «поймать» нужный запрос, а затем получить и интерпретировать его план.

Ниже разобран полный цикл работы: включение технологического журнала, поиск запроса, получение плана в обеих популярных СУБД, чтение основных операторов и типичные ошибки при анализе.

Что такое план запроса и когда его нужно смотреть

Оптимизатор СУБД для каждого запроса строит несколько вариантов выполнения и выбирает самый дешёвый по оценке стоимости. Выбор зависит от статистики распределения данных, наличия индексов и параметров запроса. Если статистика устарела или индекса под условие нет, план окажется неоптимальным — и запрос, который мог бы выполняться за миллисекунды, будет сканировать миллионы строк.

Смотреть план имеет смысл при конкретных симптомах: отчёт или проведение документа резко замедлились без изменения кода; запрос ведёт себя по-разному у разных пользователей или на разных отборах; после обновления конфигурации или СУБД деградировала производительность типовой операции. Также план проверяют после добавления нового индекса — чтобы убедиться, что оптимизатор его действительно использует.

Шаг 1. Поймать запрос через технологический журнал

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

Минимальная конфигурация для перехвата запросов к MS SQL выглядит так:

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

Для PostgreSQL вместо DBMSSQL указывают событие DBPOSTGRS. Свойство planSQLText заставляет платформу записывать в журнал текстовый план запроса, полученный от СУБД, — в ряде случаев это избавляет от ручной трассировки. Длительность события фиксируется в микросекундах, поэтому медленные запросы легко отфильтровать по значению duration.

Шаг 2. Получить план в MS SQL Server

Скопированный из ТЖ SQL-текст открывают в SQL Server Management Studio. Перед выполнением включают фактический план запроса клавишами Ctrl+M (меню Query → Include Actual Execution Plan) и запускают запрос клавишей F5. На вкладке Execution Plan появится графическое дерево операторов с процентами стоимости.

Альтернатива без выполнения запроса — оценочный план (Ctrl+L): он строится по статистике и не требует реального прогона, что безопасно для тяжёлых запросов. Однако оценочный план может расходиться с фактическим, особенно при устаревшей статистике.

Ещё один способ — перехват «живого» запроса через Profiler или Extended Events с событием Showplan XML: так вы получите план именно того экземпляра запроса, который выполнялся из 1С, с реальными параметрами. Это важно, потому что при разных значениях параметров план может отличаться (эффект parameter sniffing).

Шаг 3. Получить план в PostgreSQL

В PostgreSQL план получают командой EXPLAIN, а для фактических показателей — EXPLAIN (ANALYZE, BUFFERS). Запрос, скопированный из ТЖ (событие DBPOSTGRS), выполняют в pgAdmin или psql:

EXPLAIN (ANALYZE, BUFFERS)
SELECT ... ; -- текст запроса из технологического журнала

Опция ANALYZE реально выполняет запрос, поэтому для тяжёлых операций сначала смотрят план без неё. В выводе обращают внимание на узлы Seq Scan по большим таблицам, расхождение между ожидаемым (rows) и фактическим (actual rows) числом строк и операции сортировки с выгрузкой на диск (Sort Method: external merge).

EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM _Document123 WHERE _Fld456 = $1;

Как читать план: на что смотреть в первую очередь

План читается от самого дорогого оператора. В графическом плане SSMS толщина стрелок показывает объём передаваемых строк, а проценты — относительную стоимость. В текстовом плане PostgreSQL ориентируются на cost и actual time вложенных узлов.

Тревожные признаки в обоих СУБД схожи: сканирование таблицы или кластерного индекса там, где ожидается точечный поиск; большое расхождение оценки и факта по строкам (признак устаревшей статистики); операторы сортировки и хеш-соединений над миллионами строк; в MS SQL — предупреждения о нехватке памяти (spill to tempdb) и implicit conversion, блокирующий использование индекса.

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

Если проблемный запрос написан в модуле конфигурации, его план можно оценить без ТЖ. Для этого запрос копируют в консоль запросов (внешнюю обработку или встроенную в типовые инструменты разработчика), подставляют реальные параметры и выполняют. Такие консоли показывают время выполнения и позволяют быстро проверить гипотезы: добавить индекс, переписать условие, убрать соединение с виртуальной таблицей без отборов.

Полноценный план СУБД консоль не покажет, но связка «консоль запросов + ТЖ на тестовой базе» закрывает большинство задач: на копии базы можно свободно экспериментировать с индексами и статистикой, не рискуя продуктивом.

Что делать с найденной проблемой

Типовые решения после анализа плана: обновить статистику (в MS SQL — UPDATE STATISTICS, в PostgreSQL — ANALYZE), создать недостающий индекс через индексацию реквизитов в конфигураторе, переписать запрос — убрать соединения с виртуальными таблицами без параметров, вынести условия из ОРГАНИЗАЦИИ-уровня в параметры виртуальной таблицы, заменить В на условие по индексированному полю.

Любые изменения индексов и запросов сначала проверяют на копии базы и фиксируют план «до» и «после» — только так можно доказать, что мера дала эффект, а не просто сместила проблему.

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