Будет ли работать быстрее прямой SQL-запрос, чем запрос средствами 1С?

← На главную

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

Стоит ли переходить на прямые SQL-запросы?

Рассмотрим текущую ситуацию: платформа 1С выполняет трансляцию запросов 1С в SQL-код на лету. Этот процесс включает проверку прав доступа RLS, учет метаданных и управление транзакциями. При переходе на прямые запросы мы получаем следующие особенности:

Отсутствие выигрыша на простых операциях. В восьмой версии платформы простые запросы уже достаточно оптимизированы. Основные «тормоза» возникают не на этапе выполнения самого SQL-кода, а на этапе обработки и передачи результатов обратно в 1С.
Риск сопровождения. Имена таблиц в базе данных 1С не являются статичными. В процессе обновлений конфигурации или реструктуризации объектов (изменение типов данных, переименование реквизитов) имена таблиц могут меняться. Ваше решение, написанное сегодня, потребует постоянного переписывания при каждом обновлении конфигурации.
Проблемы с целостностью. Прямая запись в таблицы (INSERT, UPDATE, DELETE) обходит механизмы контроля транзакций 1С. Это ведет к потере логической согласованности данных. Платформа просто «не узнает» изменения, сделанные напрямую, что приведет к повреждению структуры базы.

Как правильно анализировать производительность запросов

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

Для начала используйте Технологический журнал. Он позволяет отследить длительность выполнения событий DBMSSQL (для MS SQL Server) или DBPOSTGRS (для PostgreSQL). Также для глубокого анализа можно использовать SQL Profiler или Extended Events, отслеживая события:

RPC:Completed
SQL:BatchCompleted

Эти инструменты покажут, какой именно код генерирует 1С и сколько времени уходит на его выполнение сервером баз данных.

Использование временных таблиц

Вместо попыток написать один «монструозный» SQL-запрос, разбейте задачу на этапы средствами языка запросов 1С. Использование Поместить во временную таблицу позволяет кардинально ускорить сложные выборки, так как SQL-сервер сможет построить оптимальный план выполнения для каждого промежуточного этапа.

Оптимизация индексов

Часто производительность падает из-за нехватки индексов для специфических условий отбора. Мы можем добавить дополнительные индексы в SQL Management Studio непосредственно в таблицы 1С. Важно: 1С не удаляет созданные вручную индексы при обновлении конфигурации, если они не конфликтуют со штатными.

Оптимизация кода при обработке результатов

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


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

Выводы

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