← На главную

При работе в конфигурации 1С:Розница 2.3 (а также в 1С:Управление торговлей 11, 1С:УНФ и других решениях на управляемых формах) пользователи часто сталкиваются с проблемой резкого замедления поиска в справочнике Номенклатура. Особенно остро эта проблема проявляется после обновления конфигураций, связанных с внедрением обязательной маркировки товаров, когда объемы данных и нагрузка на базу существенно возрастают.

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

Решение 1. Оптимизация и отключение полнотекстового поиска (ППД)

Механизм полнотекстового поиска данных (ППД) в 1С предназначен для быстрого нахождения информации по всем объектам базы. Однако при постоянном обновлении данных (например, при активных продажах и поступлениях товаров) индекс ППД постоянно перестраивается, что вызывает колоссальную нагрузку на дисковую подсистему и процессор.

Рассмотрим по шагам, как решить эту проблему:

1. Отключение автоматического поиска при вводе: Если база работает медленно, рекомендуется временно отказаться от динамического поиска по мере набора текста. Вместо этого приучите пользователей использовать сочетания клавиш Alt + F или Ctrl + F в списках. Это позволяет открывать стандартное окно поиска 1С, где запрос выполняется только после нажатия клавиши Enter или кнопки «Найти».
2. Переиндексация полнотекстового поиска: Часто индекс ППД замусоривается или повреждается. Для его восстановления перейдем в раздел Администрирование — Поддержка и обслуживание — Полнотекстовый поиск. Нажмем кнопку Очистить индекс, а затем выполним операцию Обновить индекс. Процесс может занять длительное время в зависимости от объема базы данных.
3. Отключение ППД: Если полнотекстовый поиск в вашей работе не критичен, его можно полностью отключить в том же меню, сняв флаг Полнотекстовый поиск разрешен. Это мгновенно снизит фоновую нагрузку на систему.

Решение 2. Очистка временных файлов (кэша) платформы 1С

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

Выясним, как правильно очистить кэш:

1. Полностью закроем программу 1С на рабочем компьютере пользователя.
2. Перейдем в каталог хранения временных файлов пользователя. Обычно в операционных системах Windows эти файлы располагаются по следующему пути:
   C:\Users\[Имя_Пользователя]\AppData\Local\1C\1cv8
   и C:\Users\[Имя_Пользователя]\AppData\Roaming\1C\1cv8.
3. Внутри этих каталогов мы увидим папки с длинными буквенно-цифровыми названиями (например, 1a2b3c4d-5e6f...). Это и есть кэш конкретных баз. Выделим их и удалим. Обратите внимание: файлы настроек и списки баз (файл ibases.v8i) удалять не нужно.
4. Также можно использовать более простой и безопасный способ: удалить базу из списка в стартовом окне 1С и добавить её заново. При этом старый кэш перестанет сопоставляться с этой базой.

Решение 3. Отключение вывода остатков и цен в форме подбора

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

Для ускорения поиска выполним следующие действия:

1. Откроем справочник Номенклатура или форму подбора товаров в документе.
2. Нажмем кнопку Еще в правом верхнем углу формы и выберем пункт Изменить форму.
3. В дереве элементов формы найдем элементы, отвечающие за вывод колонок «В наличии», «Доступно», «Остаток» и «Цена».
4. Снимем флаги напротив этих полей, чтобы отключить их отображение в списке, и нажмем Применить. Поиск начнет работать практически мгновенно, так как системе больше не придется вычислять остатки для каждой найденной позиции.

Решение 4. Ограничение индексируемых полей и изменение способа поиска

По умолчанию платформа осуществляет поиск по любому вхождению строки (режим поиска Любая часть). Это означает, что при вводе букв «про» система будет искать их и в начале наименования, и в середине («Супротек»), и в конце. Такой поиск не может эффективно использовать индексы СУБД.

Проанализируем, как это оптимизировать:

• Изменение режима поиска: В конфигураторе для элементов управления полей ввода справочника Номенклатура рекомендуется установить способ поиска Начало вместо Любая часть. Это заставит систему искать совпадения строго с первых букв слова, что существенно снижает нагрузку на базу.
• Ограничение полнотекстового поиска в Конфигураторе: Откроем свойства справочника Номенклатура в режиме конфигуратора. Перейдем на вкладку Данные и проверим свойства текстовых реквизитов (таких как «Описание», «Дополнительные свойства»). Для малозначимых текстовых полей большого объема установим свойство Полнотекстовый поиск в значение Не использовать. Оставим индексируемыми только ключевые поля: Наименование, Артикул и Штрихкод.

Решение 5. Тонкая настройка регламентных заданий ППД

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

Разберем оптимальные параметры настройки регламентных заданий:

• Обновление индекса ППД: По умолчанию данное задание запускается каждую минуту (60 секунд). Для крупных информационных баз этот интервал слишком мал и создает непрерывную нагрузку на диски. Рекомендуется увеличить интервал запуска задания до 10–15 минут или даже до 1 часа (в зависимости от требований бизнеса к актуальности поиска абсолютно новых товаров).
• Слияние индексов ППД: Это крайне ресурсоемкая операция, которая объединяет накопленные за день изменения в основной индекс. По умолчанию она может запускаться в рабочее время. Настроим расписание этого задания строго на ночные часы (например, один раз в сутки в 3:00 ночи), когда в базе нет активных пользователей.

Решение 6. Настройка режима работы сканера штрихкодов

Если основные «тормоза» и зависания системы происходят в момент подбора номенклатуры на кассе с помощью сканера штрихкодов, проблема кроется в методе подключения оборудования.

Рассмотрим эту техническую особенность подробнее:

Многие сканеры по умолчанию работают в режиме эмуляции клавиатуры (так называемый режим «в разрыв клавиатуры»). При считывании кода сканер имитирует очень быстрое нажатие клавиш на клавиатуре компьютера. 1С воспринимает это как ввод текста пользователем и запускает механизм поиска по мере ввода на каждый отправленный символ штрихкода. База данных просто не успевает обрабатывать 13 последовательных запросов за доли секунды и зависает.

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

Решение 7. Проверка целостности базы данных

Иногда поисковые механизмы «спотыкаются» о некорректные связи в базе данных, вызванные аварийными завершениями работы программы или сбоями оборудования. Наличие «битых» ссылок (объектов типа <Объект не найден...>) приводит к ошибкам при индексации.

Выполним тестирование базы:

1. Запустим базу данных в режиме Конфигуратор.
2. Обязательно создадим резервную копию информационной базы (меню Администрирование — Выгрузить информационную базу).
3. Перейдем в меню Администрирование — Тестирование и исправление.
4. Установим флаги напротив пунктов Реиндексация таблиц информационной базы, Проверка логической целостности и Проверка ссылочной целостности.
5. Нажмем кнопку Выполнить и дождемся окончания процесса. Это исправит внутренние ошибки таблиц СУБД и позволит поисковым механизмам работать в штатном режиме без задержек.