В процессе эксплуатации систем на базе 1С:Предприятие 8.3, особенно в конфигурациях типа Розница 2.3, пользователи часто сталкиваются с деградацией производительности при поиске в справочниках. Ситуация, когда у одного пользователя поиск занимает несколько минут, а у других отрабатывает мгновенно, является классической проблемой, требующей комплексного анализа. Разберем пошагово, почему это происходит и как вернуть системе былую скорость.
Проанализируем ситуацию: основной причиной «тормозов» в списках номенклатуры чаще всего является включение колонок, отображающих расчетные данные в реальном времени. К таким колонкам относятся В наличии, Доступно и Резерв. Рассмотрим подробнее механизм их работы. Когда эти столбцы активны, платформа 1С при каждом обновлении списка (скроллинг, поиск, фильтрация) выполняет сложный SQL-запрос, который соединяет основную таблицу справочника Справочник.Номенклатура с виртуальными таблицами остатков регистров накопления.
В клиент-серверном варианте это приводит к тому, что оптимизатор SQL-сервера может выбрать неэффективный план запроса. Если поиск происходит практически мгновенно при отключении столбцов остатков, значит, проблема кроется в избыточности соединений. Выясним причину, по которой это проявляется индивидуально: у конкретного пользователя могут быть сохранены специфические настройки формы, где эти колонки не просто включены, но и участвуют в сортировке или группировке, что кратно увеличивает нагрузку.
Одной из наиболее неочевидных причин является RLS (Record Level Security) — ограничение прав на уровне записей. Рассмотрим, как это работает. Даже если у пользователя установлены «Полные права», в системе могут быть активны функциональные опции, ограничивающие доступ по магазинам или складам. Когда платформа формирует запрос к базе данных, она добавляет к нему условия «ГДЕ», проверяющие права пользователя на каждую строку.
Проанализируем ситуацию в связке с остатками: SQL-запрос становится громоздким, так как проверки RLS накладываются и на справочник, и на таблицы итогов. Это приводит к тому, что индекс, который должен был ускорить поиск по наименованию, перестает использоваться эффективно. Чтобы проверить эту версию, попробуйте временно назначить пользователю роль без ограничений RLS или проверить настройки в разделе Администрирование — Настройки пользователей и прав — Ограничение доступа на уровне записей.
Если создание нового пользователя не помогает, но проблема сохраняется на конкретном рабочем месте, необходимо выполнить глубокую очистку настроек. Разберем, где 1С хранит эти данные. Помимо локального кэша на жестком диске (папки AppData/Local/1C и AppData/Roaming/1C), настройки динамических списков сохраняются в системных таблицах базы данных.
Посмотрим на алгоритм очистки настроек через интерфейс программы:
Это принудительно сбросит форму списка номенклатуры к заводскому виду, исключив влияние некорректных группировок, которые пользователь мог установить случайно.
Поскольку проблема проявляется только в клиент-серверном варианте, нельзя игнорировать состояние базы данных на SQL. Выясним, почему план запроса может быть неоптимальным. Со временем статистика распределения данных в таблицах остатков устаревает, и SQL-сервер начинает «ошибаться», выбирая Index Scan вместо Index Seek.
Для решения рекомендуется выполнить регламентные операции. Рассмотрим пример скрипта для обновления статистики, который можно запустить через SQL Server Management Studio:
-- Обновление статистики для всей базы данных
EXEC sp_updatestats;
GO
-- Очистка процедурного кэша (выполнять с осторожностью на рабочей базе)
DBCC FREEPROCCACHE;
GO
Очистка кэша планов (FREEPROCCACHE) заставит сервер заново построить планы запросов для поиска номенклатуры, что часто решает проблему «зависших» медленных поисков, возникших из-за Parameter Sniffing.
В конфигурации «Розница» версии 2.3 реализован механизм, позволяющий снизить нагрузку при выводе остатков. Если в настройках номенклатуры включен флаг Выводить остатки, система может пытаться рассчитать их в основном потоке. Проанализируем настройки программы: в последних релизах предусмотрено регламентное задание Обновление остатков на складах.
Убедимся, что:
Для окончательного подтверждения теории воспользуемся встроенным инструментом 1С. Рассмотрим порядок действий:
Если основное время (более 90%) тратится на метод ПриПолученииДанныхНаСервере или на выполнение запроса в динамическом списке, значит, мы имеем дело именно с тяжелым SQL-запросом. Посмотрим на код, который обычно вызывает задержку:
// Пример запроса в динамическом списке, который может тормозить
ВЫБРАТЬ
СправочникНоменклатура.Ссылка,
СправочникНоменклатура.Наименование,
ЕСТЬNULL(ТоварыНаСкладахОстатки.ВНаличииОстаток, 0) КАК Остаток
ИЗ
Справочник.Номенклатура КАК СправочникНоменклатура
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки КАК ТоварыНаСкладахОстатки
ПО СправочникНоменклатура.Ссылка = ТоварыНаСкладахОстатки.Номенклатура
Такой запрос при наличии RLS и большого количества записей в регистре (сотни тысяч) будет выполняться крайне медленно. Рекомендуемым решением в данном случае является либо отказ от вывода остатков в общем списке (использование отдельной кнопки или панели информации), либо переход на использование упрощенных таблиц остатков, если бизнес-процесс это позволяет.
Подводя итог, можно сказать, что «индивидуальные» тормоза поиска — это почти всегда комбинация сложных настроек формы и специфических прав доступа. Для исправления ситуации мы рекомендуем сначала отключить колонки остатков у пользователя, а затем последовательно проверять влияние RLS и актуальность индексов SQL-сервера. Совместная работа системного администратора и разработчика 1С в этом вопросе позволяет сократить время поиска с 5 минут до долей секунды.