Работа с большими справочниками в 1С:Управление торговлей 11 часто становится серьезным испытанием для производительности системы. Ситуация, когда справочник номенклатуры, содержащий более 200 000 позиций, открывается несколько минут, а подбор по остаткам практически не функционирует, является классической для файлового режима работы базы данных. В данной статье мы подробно разберем, почему файловый режим ограничивает возможности программы, как переход на SQL (клиент-серверный вариант) решает эти проблемы и какие дополнительные шаги по оптимизации необходимо предпринять.
Прежде всего, проанализируем, почему конфигурация УТ 11 ведет себя значительно тяжелее, чем старые версии (например, УТ 10.3). Основная причина кроется в архитектуре интерфейса. В современных конфигурациях на управляемых формах повсеместно используются динамические списки. Рассмотрим подробнее механизмы их работы:
Справочник.Номенклатура с таблицами цен, остатков, дополнительных реквизитов и штрихкодов.Разберем, какие преимущества дает клиент-серверный вариант работы. Многие пользователи сомневаются, стоит ли переходить на SQL, если «железо» остается тем же. Ответ в большинстве случаев — да, стоит. Проанализируем технические аспекты:
Эффективное построение планов запросов. SQL-сервер обладает мощным оптимизатором, который строит план выполнения запроса на основе статистики. Он «понимает», какие индексы использовать, чтобы выдернуть 45 строк для отображения на экране, не сканируя все 200 000 позиций.
Постраничная подгрузка данных. На клиент-сервере механизм ДинамическийСписок работает максимально эффективно. Система запрашивает ровно столько данных, сколько помещается на экране пользователя. В файловом режиме, из-за специфики движка, часто происходит избыточное чтение данных во временные файлы на локальном диске пользователя.
Использование Shared Memory. Если сервер 1С и сервер SQL установлены на одном физическом компьютере, можно настроить протокол Shared Memory (общая память). Это позволяет передавать данные между компонентами системы практически мгновенно, минуя сетевой стек, что критически важно для тяжелых форм списка.
Даже после перехода на SQL могут оставаться «узкие места». Выясним причины тормозов в подборе номенклатуры, который часто называют «мертвым» при включении отображения остатков. Проанализируем ситуацию:
Когда в форме подбора включена галочка «Показывать остатки», система при каждом перемещении курсора или при обновлении списка выполняет запрос к регистру накопления ЗапасыНаСкладах (или ТоварыНаСкладах). Для оптимизации этого процесса выполним следующие действия:
Если справочник продолжает тормозить, воспользуемся инструментами разработчика. Рассмотрим пошагово, как найти причину замедления:
ПриВыводеСтроки или ПриПолученииДанных (в старых формах) или сложные вычисления в расширениях.TOP 0 или огромное количество соединений LEFT OUTER JOIN, значит, структуру динамического списка нужно упрощать.Посмотрим на пример кода, который может помочь программно оптимизировать работу с остатками, если вы используете собственные алгоритмы вывода:
// Пример установки параметров получения остатков для ускорения выборки
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ТоварыНаСкладахОстатки.Номенклатура,
| ТоварыНаСкладахОстатки.ВНаличииОстаток
|ИЗ
| РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, ) КАК ТоварыНаСкладахОстатки";
Запрос.УстановитьПараметр("Период", КонецДня(ТекущаяДата()));
// Важно: Использование пустых фильтров по номенклатуре в больших циклах недопустимо!
Нельзя забывать и о «железе». Переход на SQL требует определенных ресурсов. Проанализируем минимальные требования для комфортной работы справочника в 200 000 позиций:
Подводя итог, можно однозначно утверждать: для УТ 11 со справочником в 200 000 позиций перевод базы на SQL является не просто желательным, а обязательным условием нормальной работы. Файловый режим на таких объемах не способен обеспечить приемлемую скорость отклика интерфейса из-за архитектурных ограничений платформы 8.3 и сложности самой конфигурации.
После перехода на SQL обязательно выполните регламентные операции: обновление статистики и дефрагментацию индексов. Это позволит серверу базы данных всегда выбирать оптимальный путь к вашим данным и обеспечит мгновенное открытие даже самых нагруженных списков.