SQL в 1С: что это и как работает связка платформы с базой данных

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

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

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

Как 1С хранит данные: файловый и клиент-серверный режимы

Файловый вариант — самый простой: вся база лежит в одном файле 1Cv8.1CD в сетевой папке или на локальном диске. Никакой внешней СУБД здесь нет, платформа сама читает и пишет этот файл. Такой режим подходит для небольших баз с несколькими пользователями и не требует администрирования сервера.

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

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

Язык запросов 1С и его отличия от SQL

Встроенный язык запросов 1С внешне напоминает SQL: те же ключевые слова ВЫБРАТЬ (SELECT), ИЗ (FROM), ГДЕ (WHERE), СГРУППИРОВАТЬ ПО (GROUP BY). Но оперирует он не таблицами базы данных, а объектами метаданных: Справочник.Номенклатура, Документ.РеализацияТоваровУслуг, РегистрНакопления.Продажи.

Пример простого запроса на языке 1С:

ВЫБРАТЬ
Номенклатура.Ссылка КАК Товар,
СУММА(Продажи.Количество) КАК Количество
ИЗ
Справочник.Номенклатура КАК Номенклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.Продажи.Обороты КАК Продажи
ПО Номенклатура.Ссылка = Продажи.Номенклатура
СГРУППИРОВАТЬ ПО
Номенклатура.Ссылка

Отличий несколько. Во-первых, язык 1С не содержит команд изменения данных — нет аналогов INSERT, UPDATE, DELETE: запись выполняется только объектными методами (Записать(), Провести()). Во-вторых, есть специфические конструкции: виртуальные таблицы (Обороты, Остатки, СрезПоследних), итоги, иерархия, разрез периодичности. В-третьих, платформа автоматически добавляет в SQL-запросы условия по разделителям данных и правам доступа на уровне записей (RLS).

Именно платформа транслирует такой запрос в SQL конкретной СУБД, подставляя реальные имена таблиц вида _Reference123, _Document456, _AccumRg789. Поэтому один и тот же запрос 1С корректно работает и на MS SQL Server, и на PostgreSQL без изменений.

Как платформа транслирует запросы в SQL

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

Увидеть реальный SQL-текст можно через технологический журнал — штатный механизм логирования платформы. В нём фиксируются события DBMSSQL (для MS SQL Server) или DBPOSTGRS (для PostgreSQL) с полным текстом запроса, параметрами и длительностью выполнения. Это основной инструмент диагностики медленных операций.

Дополнительно план выполнения запроса анализируется средствами самой СУБД: в MS SQL Server — через Execution Plan и Extended Events, в PostgreSQL — через команду EXPLAIN. По плану видно, используется ли индекс или выполняется полное сканирование таблицы, что и определяет скорость.

1. 1
   Включите технологический журнал на сервере 1С с фильтром по событиям DBMSSQL и длительности больше заданного порога
2. 2
   Воспроизведите проблемную операцию (проведение документа, построение отчёта)
3. 3
   Найдите в логе самые длительные SQL-запросы и скопируйте их текст
4. 4
   Выполните запрос в среде СУБД (SQL Server Management Studio или pgAdmin) с отображением плана выполнения
5. 5
   Проверьте, используются ли индексы; при необходимости измените запрос 1С, индексацию в конфигураторе или статистику СУБД

Когда допустимы прямые SQL-запросы к базе 1С

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

Изменение данных напрямую через INSERT, UPDATE или DELETE категорически запрещено. Платформа поддерживает служебную логику, которая не выполнится при прямой записи: контроль итогов регистров, версионирование объектов, бизнес-логика в обработчиках, последовательности документов, планы обмена. Результат — рассогласованные итоги, битые ссылки и база, которую придётся восстанавливать из копии.

Ещё одно ограничение — блокировки. Прямой тяжёлый SELECT без подсказок может заблокировать таблицы и остановить работу пользователей. Для чтения следует использовать режим сниженной изоляции (в MS SQL Server — подсказку WITH (NOLOCK) или снимок изоляции), понимая, что данные при этом могут быть неполностью согласованными.

Настройка и обслуживание СУБД для 1С

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

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

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

Практическая диагностика: как понять, что проблема в SQL-уровне

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

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

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

Как проверить результат

Длительность проблемной операции до и после изменений

Норма

Время сократилось в разы и стабильно при повторных запусках

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

Время не изменилось или стало хуже — причина не найдена

План выполнения запроса в СУБД

Норма

Используются Index Seek, читается мало строк

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

Полное сканирование таблиц (Scan) по большим регистрам

Ошибки блокировок в технологическом журнале

Норма

Таймауты и взаимоблокировки исчезли

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

Ошибки продолжаются — нужен анализ уровня изоляции и порядка обращения к таблицам

FAQ

Нужно ли учить SQL, чтобы работать разработчиком 1С?

Для большинства задач достаточно встроенного языка запросов 1С. Но базовое понимание SQL — как работают соединения, индексы, планы выполнения — сильно помогает писать быстрые запросы и разбираться в проблемах производительности клиент-серверных баз.

Можно ли подключиться к базе 1С из Excel или Power BI напрямую?

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

Почему нельзя просто удалить ненужный документ через SQL?

Документ связан с движениями по регистрам, последовательностями, итогами и ссылками из других объектов. Прямое удаление строки из таблицы документа оставит все эти связанные данные в несогласованном состоянии. Штатное удаление или отмена проведения через платформу выполняет всю цепочку корректно.

Что выбрать для 1С: MS SQL Server или PostgreSQL?

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

Как узнать, какой SQL-запрос формирует конкретный отчёт?

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