Часто проблема медленной работы 1С кроется не в «слабом железе» или настройках SQL сервера, а в неоптимальном коде конфигурации. Расширения, внешние обработки и доработки, написанные без учета стандартов производительности 1С, могут положить даже мощный сервер. В этой статье разберем 10 главных ошибок программистов 1С, из-за которых база начинает тормозить.
Характерные симптомы «плохого кода» в 1С
Как понять, что 1С тормозит именно из-за ошибок программиста, а не из-за инфраструктуры?
- База тормозит только при выполнении конкретных операций (проведение определенного документа, открытие конкретного справочника, формирование одного отчета).
- Увеличение мощности сервера (CPU, RAM) не дает существенного прироста скорости.
- Проблемы начались сразу после добавления нового расширения или обновления нетиповой конфигурации.
- В Технологическом Журнале (ТЖ) фиксируются длительные серверные вызовы, избыточные блокировки (TTIMEOUT) или неоптимальные SQL запросы к одним и тем же таблицам.
1С тормозит из-за доработок?
Проведу технический аудит производительности вашей 1С: найду медленные участки кода, запросы в цикле и завышенные блокировки. Покажу, как ускорить систему в 2-3 раза без покупки нового сервера.
Бесплатная диагностика проблемы →Топ-10 критических ошибок разработчиков 1С
1. Запросы в цикле
Это абсолютный «лидер» среди причин деградации производительности. Выполнение SQL-запроса внутри цикла к базе данных многократно увеличивает количество обращений к серверу СУБД, нагружает сеть и диск.
В цикле `Для Каждого Строка Из ТаблицаЦикла Цикл` встречается конструкция `Запрос.Выполнить().Выбрать()` или получение реквизитов через точку объекта (`Строка.Номенклатура.Артикул`).
Правильное решение:Формировать массив значений, передавать его параметром в один большой запрос перед циклом (условие `В (&МассивЗначений)`) и затем обходить уже подготовленные результаты выборки.
2. Получение данных через точку («объектная модель»)
Использование конструкции типа `ДокументСсылка.Контрагент.ОсновнойДоговор.Организация` кажется удобным при написании кода, но под капотом платформа 1С на каждую такую "точку" генерирует отдельный неоптимальный SQL-запрос к БД.
Особенно критично использование обращений через точку в динамических списках или при обходе больших табличных частей.
3. Использование виртуальных таблиц без параметров
Виртуальные таблицы (например, `Остатки`, `Обороты`, `ОстаткиИОбороты`) очень удобны, но если обращаться к ним без передачи параметров во внутренние условия (например, Период или Отбор по номенклатуре), СУБД считывает всю историю регистра целиком, прежде чем отфильтровать результаты.
Всегда ограничивайте виртуальные таблицы параметрами. Конструкция `РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, Номенклатура В (&Список))` отработает в десятки раз быстрее, чем фильтрация уже полученного результата в секции `ГДЕ`.
4. Запись объектов в цикле (без использования транзакций и наборов записей)
Построчная запись справочников или документов (`Объект.Записать()`) внутри большого цикла создает колоссальную нагрузку на сервер. Платформа 1С для каждого объекта инициирует десятки проверок подписок на события, контроль прав доступа и запись в журнал регистрации.
5. Выполнение тяжелых алгоритмов на клиенте (`&НаКлиенте`)
Платформа 1С 8.3 (особенно управляемые формы) требует четкого разделения контекста. Вызов процедур изменения данных, циклические обходы таблиц БД на стороне клиента (в обход сервера) приводят к тысячам мелких серверных вызовов («болтовня» по сети), что буквально вешает 1С на медленных каналах связи или RDP.
6. Отсутствие необходимых индексов (или игнорирование покрывающих)
Даже идеально написанный запрос будет тормозить, если СУБД вынуждена выполнять полное сканирование таблиц (Table Scan / Index Scan). Программисты часто добавляют новые реквизиты или регистры сведений, забывая установить признак «Индексировать» для полей, по которым будет идти частый поиск или соединение.
7. Избыточные транзакции и необоснованные блокировки таблиц
При использовании автоматического режима управления блокировками или неправильной настройке управляемых блокировок программист может нечаянно заблокировать всю таблицу или регистр. В результате другие пользователи выстраиваются в очередь и видят зависание 1С.
События `TTIMEOUT` (ожидание блокировки) и `TDEADLOCK` (взаимоблокировки).
8. Сложные составные соединения в запросах (OR в секции ПО)
Использование логического `ИЛИ` (OR) в условии соединения таблиц (`ЛЕВОЕ СОЕДИНЕНИЕ... ПО (Условие1 ИЛИ Условие2)`) гарантированно приводит к отказу оптимизатора СУБД от использования индексов. Запрос будет выполняться максимально долго.
9. Передача больших объемов данных с сервера на клиент и обратно
Возврат с сервера на клиент массивных таблиц значений, структур или списков значений ради получения пары строчек приводит к существенной задержке и избыточному потреблению оперативной памяти на сервере приложения 1С (rphost).
10. Отказ от использования временных таблиц
Попытки решить сложную аналитическую задачу одним гигантским многоэтажным запросом с вложенными подзапросами часто приводят оптимизатор MS SQL Server или PostgreSQL в замешательство. Использование менеджера временных таблиц позволяет шаг за шагом агрегировать данные надежно и быстро.
Как найти "узкие места" в нетиповой конфигурации?
- Технологический журнал (ТЖ): Настройте анализ длительных серверных вызовов (`CALL`) и долгих запросов СУБД (`DBMSSQL` или `DBPOSTGRS`).
- Анализ производительности APDEX: Встроенный механизм БСП поможет замерять скорость критически важных операций напрямую у пользователей.
- Профайлер SQL: (SQL Profiler или `pg_stat_statements`) для выявления ТОП-10 запросов по процессорному времени и чтению диска.
- Аудит кода: Проверка измененных объектов конфигурации, расширений и внешних отчетов на предмет антипаттернов (запросы в цикле и пр.).