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

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

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

Без плана запроса оптимизация превращается в гадание: можно переписать запрос десять раз и не попасть в причину. С планом видно конкретную дорогую операцию — например, Index Scan по регистру накопления на десятки миллионов строк вместо Index Seek по отбору, который разработчик забыл наложить.

Что именно показывает план запроса

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

Ключевые операции, которые нужно уметь распознавать: Index Seek (точечный поиск по индексу — быстро и хорошо), Index Scan или Table Scan (чтение всего индекса или всей таблицы — медленно на больших объёмах), Nested Loops и Hash Match (способы соединения таблиц), Sort (сортировка, дорогая при большом числе строк). Также план показывает ожидаемое и фактическое количество строк — большое расхождение между ними указывает на устаревшую статистику.

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

Самый доступный способ — консоль запросов с функцией показа плана. Существуют консоли, которые выполняют запрос на сервере 1С и выводят текст сгенерированного SQL вместе с планом выполнения (для MS SQL Server — в текстовом или графическом виде). Такую консоль можно найти в составе инструментов разработчика или подключаемых обработок; типовая «Консоль запросов» из демонстрационных конфигураций план не показывает.

Второй путь — технологический журнал (ТЖ). Включив в конфигурационном файле logcfg.xml сбор событий DBMSSQL (или DBPOSTGRS для PostgreSQL) с длительностью, вы получите текст SQL-запросов, которые платформа отправила в СУБД, и время их выполнения. Далее этот SQL выполняется непосредственно в Management Studio или psql с включённым отображением плана.

Третий вариант — штатные средства СУБД. В MS SQL Server это «Включить действительный план выполнения» в SSMS, а также динамические представления sys.dm_exec_query_stats и кэш планов для поиска самых тяжёлых запросов. В PostgreSQL — команда EXPLAIN ANALYZE, которая показывает план с фактическим временем каждого шага.

1. 1
   Настройте logcfg.xml: событие DBMSSQL, свойство Duration, каталог для логов на сервере 1С
2. 2
   Воспроизведите проблему: запустите медленный отчёт или проведение документа
3. 3
   Найдите в журнале событие DBMSSQL с большим значением Durability и скопируйте текст SQL
4. 4
   Выполните этот SQL в SSMS с включённым действительным планом выполнения
5. 5
   Найдите в плане операции с максимальной стоимостью и сопоставьте их с таблицами запроса 1С

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

Читать план начинают с самых дорогих операций — в графическом плане SSMS процент стоимости указан под каждым оператором. Читается план справа налево и сверху вниз: данные текут от операций чтения к операциям соединения и выдачи результата.

Первый тревожный признак — Scan по большой таблице там, где ожидался Seek. Например, запрос к регистру сведений с отбором по измерению «Номенклатура», а в плане — Clustered Index Scan: значит, подходящего индекса нет или оптимизатор не смог его использовать (частая причина — функция над полем в условии или неявное преобразование типов). Второй признак — толстые стрелки между операторами: чем толще линия, тем больше строк передаётся, и если на входе соединения миллионы строк, а на выходе сотни, фильтрация происходит слишком поздно.

Третий важный показатель — расхождение Estimated Number of Rows и Actual Number of Rows. Если оптимизатор ожидал 10 строк, а пришло 500 000, он мог выбрать Nested Loops там, где нужен Hash Match, и запрос будет выполняться на порядки дольше. Это почти всегда означает устаревшую статистику по таблице.

Контрольные точки

Как отличить хороший план от плохого

Операция чтения основной таблицы

Норма

Index Seek по индексу, покрывающему отбор запроса

Тревожный признак

Index Scan или Table Scan по таблице с миллионами строк

Количество строк на входе соединений

Норма

Сотни-тысячи строк после ранней фильтрации

Тревожный признак

Миллионы строк поступают в соединение до применения отбора

Оценка и факт строк

Норма

Estimated и Actual отличаются незначительно

Тревожный признак

Расхождение в десятки и сотни раз — устаревшая статистика

Сортировка и временные таблицы

Норма

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

Тревожный признак

Sort или Spool над большим потоком строк, уход в tempdb

Типичные причины плохих планов в запросах 1С

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

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

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

Как исправить план: практические приёмы

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

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

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

Маршрут решения

Как выбрать действие по симптому

В плане виден Scan по таблице регистра, а в запросе есть отбор по измерениюПроверьте, не применяется ли к полю функция и не нарушен ли порядок полей отбора относительно индекса; перенесите отбор в параметры виртуальной таблицы

Estimated и Actual число строк различаются в сотни разОбновите статистику по таблице на стороне СУБД и снимите план повторно

Дорогой Sort или Hash Match над миллионами строкСократите выборку раньше: добавьте отборы, уберите лишние поля, рассмотрите временную таблицу с предварительной фильтрацией

Запрос медленный только при определённых значениях параметровПроверьте эффект parameter sniffing — закешированный план под чужие параметры; рассмотрите перекомпиляцию или переработку запроса

План хороший, но запрос всё равно ждётСмотрите ожидания и блокировки: проблема может быть не в плане, а в конкуренции за ресурсы или управляемых блокировках 1С

Ограничения и когда нужен специалист

Анализ планов в файловом варианте 1С сильно ограничен: встроенная СУБД платформы не предоставляет развитых инструментов просмотра планов, и основными средствами остаются замер производительности и корректировка текста запроса. Полноценная работа с планами возможна в клиент-серверном варианте на MS SQL Server или PostgreSQL.

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

Как проверить, что оптимизация удалась

Единственный надёжный способ — сравнение «до» и «после» в одинаковых условиях. Зафиксируйте до изменений: время выполнения запроса, план, число логических чтений (в SSMS — SET STATISTICS IO, TIME ON). После изменений повторите замер на тех же данных и с теми же параметрами. Хороший результат — снижение времени выполнения и числа чтений в разы, а не на проценты, и исчезновение из плана сканирований больших таблиц.

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

Частые вопросы о планах запросов в 1С

Можно ли посмотреть план запроса без доступа к SQL Server?

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

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

Чаще всего причина в разных значениях параметров: СУБД компилирует план под значения параметров первого выполнения (parameter sniffing), и план, хороший для одних отборов, плох для других. Также в отчёте СКД может добавлять к запросу собственные соединения и итоги, меняя итоговый SQL. Сравните реальные тексты SQL из технологического журнала в обоих случаях.

Что делать, если план показывает Scan по таблице документов?

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

Помогает ли перезапуск сервера 1С или SQL при медленных запросах?

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

Нужно ли анализировать план для каждого запроса в конфигурации?

Нет, это неоправданно трудозатратно. Анализируйте планы только для запросов, которые реально создают нагрузку: их находят через технологический журнал по длительности или через динамические представления СУБД по суммарному времени выполнения. Оптимизация запроса, выполняющегося раз в день за 100 мс, не даст ничего, даже если его план неидеален.