Почему тормозит подбор номенклатуры в УТ 10.3 и как это исправить?

← На главную

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

В данной статье мы подробно разберем, почему это происходит, проанализируем «проблемный» программный код и определим шаги по восстановлению производительности системы.

Выясним причину: почему поиск становится медленным

Для начала проанализируем ситуацию. Когда пользователь вводит текст в поле поиска подбора, система инициирует событие АвтоПодбор или ПриИзменении. В типовой УТ 10.3 это часто запускает механизм динамического формирования списка номенклатуры с одновременным расчетом остатков и цен. В файловом варианте базы данных (формат .1CD), работающем по сети через общую папку, любая сложная операция с данными превращается в «узкое горлышко» из-за особенностей протокола SMB и механизма блокировок 1С.

Рассмотрим основные факторы, влияющие на скорость:

Сложные запросы к виртуальным таблицам: Попытка получить остатки сразу из пяти-шести регистров в одном запросе.
Работа через сетевой путь: При каждом нажатии клавиши система гоняет по сети огромные объемы индексных файлов.
Неактуальные итоги: После свертки или переноса данных границы итогов могут быть не рассчитаны, что заставляет систему вычислять остатки «на лету» с начала времен.
Фрагментация файла БД: После удаления данных (свертки) в файле .1CD образуются пустоты, замедляющие чтение.

Проанализируем «тяжелый» запрос остатков

Как показывает практика и отладка (проведенная в сообщении 9), основной виновник тормозов — запрос, собирающий остатки. Давайте посмотрим на его структуру и выясним, что с ним не так. Типовой механизм пытается объединить данные из РегистрНакопления.ТоварыНаСкладах, ТоварыВРознице, ТоварыОрганизаций и других через ОБЪЕДИНИТЬ ВСЕ, а затем выполняет ЛЕВОЕ СОЕДИНЕНИЕ с другими виртуальными таблицами остатков (резервы, товары к передаче).

Пример кода, который «кладет» файловую базу:


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

В чем главная ошибка этого запроса? Во-первых, использование вложенных запросов в объединениях. В файловой базе оптимизатор запросов работает гораздо слабее, чем в MS SQL Server. Во-вторых, выполнение соединений (JOIN) между виртуальными таблицами. Для файловой СУБД это крайне тяжелая операция. В-третьих, обратите внимание на условие ВЫБОР КОГДА ... внутри параметров виртуальной таблицы. Это заставляет систему выполнять полный скан таблиц вместо использования индексов.

Разберем по шагам: как оптимизировать работу

Если вы столкнулись с подобной проблемой, рекомендуем придерживаться следующего алгоритма действий.

Шаг 1: Обслуживание базы данных после свертки

Если тормоза начались после свертки, это означает, что физическая структура файла базы данных пришла в упадок. Выполните следующие действия в Конфигураторе:

Тестирование и исправление (ТиИ): Обязательно выберите пункты «Реиндексация таблиц» и «Сжатие таблиц информационной базы». Последнее критически важно: оно удаляет «дыры» из файла .1CD, оставшиеся после удаления документов сверткой.
Пересчет итогов: Зайдите в меню «Операции» — «Управление итогами» и убедитесь, что итоги рассчитаны по текущий месяц. Если итоги «слетели», 1С будет каждый раз сканировать все движения регистров, чтобы вычислить остаток.

Шаг 2: Изменение архитектуры работы (RDP)

Работа файловой базы «по сети» (через shared folder) — это тупиковый путь для 4-х и более пользователей. Рассмотрим переход на Удаленный рабочий стол (RDP). Когда база и клиентское приложение работают на одном сервере, сетевые задержки при передаче данных между движком БД и приложением исчезают. Это дает прирост скорости подбора в 5-10 раз без изменения кода.

Шаг 3: Оптимизация запроса в коде

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


// 1. Помещаем во временную таблицу список нужной номенклатуры
Запрос.Текст = "ВЫБРАТЬ Ссылка ПОМЕСТИТЬ ВТ_Список ИЗ Справочник.Номенклатура ГДЕ ...";

// 2. Получаем остатки по складам в другую ВТ
Запрос.Текст = "ВЫБРАТЬ Номенклатура, КоличествоОстаток ПОМЕСТИТЬ ВТ_Остатки 
                ИЗ РегистрНакопления.ТоварыНаСкладах.Остатки(&Дата, Номенклатура В (ВЫБРАТЬ Ссылка ИЗ ВТ_Список))";

// 3. Финальное соединение уже проиндексированных временных таблиц
Запрос.Текст = "ВЫБРАТЬ ВТ_Список.Ссылка, ЕСТЬNULL(ВТ_Остатки.КоличествоОстаток, 0) ...";

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

Шаг 4: Отключение «лишнего» функционала

Часто пользователям в подборе не нужны остатки в реальном времени по всем регистрам сразу. Проанализируем настройки формы подбора:

Попробуйте отключить флажки «Показывать остатки» или «Остатки по организациям».
Если тормоза прекратились — значит, проблема именно в коде получения остатков (см. Шаг 3).
Проверьте использование Полнотекстового поиска (ПП). Если индекс ПП поврежден, автоподбор может пытаться к нему обратиться и зависать. Рекомендуется либо обновить индекс, либо полностью отключить его в свойствах базы.

Подведем итоги

Тормоза подбора в УТ 10.3 на файловой базе — это комплексная проблема. Она лечится сжатием таблиц после свертки, актуализацией итогов и, в идеале, переходом на RDP-режим. Если программный код подбора был изменен (кастомизирован), необходимо переписать запросы с использованием временных таблиц, избегая прямых соединений виртуальных таблиц остатков. Помните: файловая 1С любит простые, последовательные операции, а не многоэтажные конструкции, привычные для SQL-серверов.