Как получить план запроса в 1С и проанализировать его

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

В экосистеме 1С есть несколько путей получения плана: встроенные возможности консоли запросов, технологический журнал платформы и штатные инструменты самой СУБД (MS SQL Server, PostgreSQL, Oracle). Каждый способ даёт разный уровень детализации и подходит для своих задач.

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

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

План запроса — это дерево операций, которое строит оптимизатор СУБД перед выполнением: сканирование таблиц, поиск по индексам, соединения, сортировки, агрегации. Один и тот же запрос может выполняться миллисекунды или минуты в зависимости от того, какой план выбрал оптимизатор.

Анализ плана нужен, когда запрос или отчёт работает медленно, когда документ проводится неприемлемо долго, когда пользователи жалуются на «подвисания» при открытии форм. Также план полезен для проверки после оптимизации: вы сравниваете план до и после изменения запроса и убеждаетесь, что индекс реально задействован, а сканирование таблицы исчезло.

Важно понимать двуслойность проблемы: платформа 1С транслирует запрос на встроенном языке в SQL, и итоговый SQL-текст может существенно отличаться от того, что написал разработчик. Поэтому анализировать нужно именно тот SQL, который ушёл на сервер, а не только исходный текст запроса в конфигураторе.

Получение плана через консоль запросов

Самый доступный способ — консоль запросов. Штатная консоль из состава типовых инструментов разработчика (ИР) и многие сторонние консоли умеют показывать план выполнения запроса. Порядок работы обычно такой: открываете консоль в режиме предприятия, вставляете текст запроса, заполняете параметры и запускаете выполнение с включённой опцией показа плана.

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

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

1. 1
   Откройте консоль запросов в режиме предприятия под пользователем с достаточными правами
2. 2
   Вставьте текст запроса и заполните все параметры реальными значениями
3. 3
   Включите опцию показа плана выполнения (в ИР — соответствующая кнопка на панели)
4. 4
   Выполните запрос и изучите план: ищите сканирования таблиц вместо поиска по индексу
5. 5
   Сохраните текст SQL и план для сравнения после оптимизации

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

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

Настройка сводится к созданию файла logcfg.xml в каталоге конфигурации технологического журнала на сервере 1С. В файле описываются события, которые нужно фиксировать: для MS SQL это DBMSSQL, для PostgreSQL — DBPOSTGRS, плюс событие EXCP для исключений. Дополнительно указывают порог длительности, чтобы не собирать лишнее.

После воспроизведения проблемы журнал анализируют: находят события с большой длительностью, извлекают SQL-текст и параметры, затем выполняют этот 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="all"/>
  </log>
</config>

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

MS SQL Server

Для MS SQL план смотрят в SQL Server Management Studio. Вставьте перехваченный SQL-текст в новое окно запроса, подставьте значения параметров и нажмите «Display Estimated Execution Plan» (Ctrl+L) для оценочного плана или включите «Include Actual Execution Plan» (Ctrl+M) и выполните запрос для фактического. Фактический план ценнее: он показывает реальное количество строк на каждом шаге, а не оценку оптимизатора.

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

PostgreSQL

В PostgreSQL план получают командой EXPLAIN, а для фактических показателей — EXPLAIN (ANALYZE, BUFFERS). Опция ANALYZE реально выполняет запрос, поэтому на тяжёлых запросах в боевой базе применяйте её осторожно. BUFFERS покажет чтения страниц из буферного кэша и с диска — это помогает отличить проблему плана от проблемы нехватки памяти.

EXPLAIN (ANALYZE, BUFFERS)
SELECT ... FROM ваш_запрос;

Файловый режим

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

На что смотреть в плане запроса

Первое, что ищут в плане, — операции полного сканирования таблиц (Table Scan, Clustered Index Scan, Seq Scan) на больших таблицах. Их наличие там, где ожидался поиск по индексу (Index Seek, Index Scan), означает, что оптимизатор не смог подобрать индекс: либо его нет, либо условие запроса написано так, что индекс неприменим.

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

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

Типичные ошибки при работе с планом запроса

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

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

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

Практические рекомендации по оптимизации

После получения плана работайте по приоритетам. Сначала устраните сканирования больших таблиц: проверьте, что условия накладываются на индексированные поля, а в запросах к виртуальным таблицам заданы отборы по измерениям. Затем посмотрите на порядок соединений: в запросах 1С помогает явное сокращение выборки на ранних этапах через временные таблицы.

Пакетное выполнение с временными таблицами — один из самых эффективных приёмов: вы сначала отбираете узкое множество данных во временную таблицу с индексом, а потом соединяете её с остальными таблицами. Это даёт оптимизатору понятную и дешёвую структуру плана.

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

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