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

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

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

Архитектура связки: кто за что отвечает

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

Такое разделение означает, что «запрос 1С» и «запрос SQL» — разные вещи. Запрос на встроенном языке 1С описывает выборку в терминах метаданных (Документ.РеализацияТоваровУслуг), а сервер 1С преобразует его в SQL-оператор с обращением к физическим таблицам вида _Document123. Имена физических таблиц генерируются платформой и не предназначены для прямого использования.

Выбор СУБД влияет на стоимость владения и тонкости настройки, но не на логику конфигурации: одна и та же база может быть выгружена в файл и развёрнута на другой СУБД через выгрузку/загрузку в конфигураторе.

Как 1С хранит данные в таблицах SQL

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

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

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

Как запрос 1С превращается в SQL

Когда код выполняет запрос вида «ВЫБРАТЬ ... ИЗ Документ.РеализацияТоваровУслуг», сервер 1С строит дерево запроса по метаданным, определяет нужные таблицы и соединения, после чего генерирует текст SQL и отправляет его в СУБД с параметрами. Виртуальные таблицы (например, РегистрНакопления.Товары.Остатки) превращаются в соединение таблицы итогов с таблицей движений.

Качество сгенерированного SQL зависит от того, как написан запрос на языке 1С. Соединение с виртуальной таблицей без отбора, выборка «ВЫБРАТЬ *» по духу, обращение к данным через точку от ссылки («разыменование») — всё это порождает тяжёлые планы выполнения. СУБД при этом честно выполняет то, что ей прислали: платформа не исправит неоптимальный запрос за разработчика.

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Реализация.Ссылка,
| Реализация.СуммаДокумента
|ИЗ
| Документ.РеализацияТоваровУслуг КАК Реализация
|ГДЕ
| Реализация.Дата МЕЖДУ &Начало И &Конец";
Запрос.УстановитьПараметр("Начало", НачалоМесяца(ТекущаяДатаСеанса()));
Запрос.УстановитьПараметр("Конец", КонецМесяца(ТекущаяДатаСеанса()));
Результат = Запрос.Выполнить().Выгрузить();

Увидеть реальный SQL-текст помогают инструменты: технологический журнал на стороне сервера 1С (события DBMSSQL, DBPOSTGRS), трассировка SQL Server Profiler или Extended Events, pg_stat_statements для PostgreSQL. По ним определяют, какой именно оператор выполняется долго и какой план выбрала СУБД.

Транзакции и блокировки

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

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

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

Настройка СУБД под нагрузку 1С

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

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

1. 1
   Воспроизведите проблему и зафиксируйте конкретную операцию: документ, отчёт, время выполнения.
2. 2
   Включите технологический журнал на сервере 1С с отбором по событиям СУБД длительностью свыше порога.
3. 3
   Найдите самый тяжёлый SQL-запрос и снимите его план выполнения в СУБД.
4. 4
   Проверьте статистику и фрагментацию индексов по затронутым таблицам, выполните обслуживание.
5. 5
   Если план неоптимален из-за запроса конфигурации — передайте запрос разработчику на доработку.
6. 6
   Повторите замер после изменений и сравните длительность операции.

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

Типичные ошибки и ограничения

Самая опасная ошибка — «починить» данные напрямую в SQL. Даже безобидный UPDATE одного поля в таблице документа не обновляет итоги регистров и служебные структуры, и рассогласование всплывёт позже — в отчётах или при обмене. Вторая частая ошибка — строить отчётность прямыми SELECT к рабочей базе в часы пик: тяжёлые запросы конкурируют с пользователями за память и блокировки. Для аналитики правильнее поднять копию базы или реплику.

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

Как проверить, что связка работает нормально

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

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

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