В этой статье разберем распространенную проблему, с которой сталкиваются разработчики и администраторы 1С: динамический список на управляемой форме начинает сильно «тормозить» или полностью зависать на несколько минут после сохранения или перезаписи элемента, на котором основан список. При этом открытие самой формы и навигация по списку могут работать быстро. Проанализируем причины такого поведения и рассмотрим по шагам, как диагностировать и устранить проблему.
Рассмотрим типичный сценарий. У нас есть форма со сложным динамическим списком, который использует левые соединения для получения дополнительных данных. Например, список справочника «Операции» соединяется с регистром сведений «СтатусыОпераций» для отображения актуального статуса.
Проблема проявляется в момент перезаписи элемента справочника. Интерфейс зависает, а замер производительности указывает на строку кода, где происходит обращение к текущим данным списка, например:
Процедура СписокПриИзменении(Элемент)
// Зависание происходит на этой строке
ТекущиеДанныеСписка = Элемент.ТекущиеДанные;
...
КонецПроцедуры
Это говорит о том, что проблема не в самом коде обработчика, а в механизме обновления данных списка. Платформа 1С после изменения данных пытается обновить строку в списке, для чего повторно выполняет запрос к базе данных. Если этот запрос неэффективен, мы получаем длительное ожидание.
Часто зависание усугубляется при работе со «старыми» записями. Это может быть косвенным признаком проблем с индексацией или статистикой данных в СУБД.
Прежде чем вносить изменения, необходимо точно определить, что именно вызывает замедление. Рассмотрим основные методы диагностики.
Анализ плана запроса в SQL. Это самый надежный способ понять, как СУБД выполняет ваш запрос. Для этого можно использовать SQL Server Profiler или Технологический журнал 1С с настроенным отбором по событию DBMSSQL. В момент зависания отследите запрос, который выполняется дольше всего. Изучите его план выполнения: ищите операции Table Scan или Index Scan по большим таблицам. В идеале должны использоваться операции Index Seek, указывающие на эффективное использование индексов.
Проверка индексов. Даже если поле, по которому идет соединение или отбор, проиндексировано (например, является ведущим измерением регистра), со временем индексы могут фрагментироваться. Это снижает их эффективность, и СУБД может перейти к полному сканированию таблицы. Убедитесь, что все поля, используемые в условиях соединения (ПО) и фильтрации (ГДЕ), входят в состав подходящих индексов.
Влияние отборов. Попробуйте воспроизвести проблему с разными настройками отбора в списке. Если список тормозит только при установленном отборе по определенному полю (например, по вычисляемому статусу), это верный признак того, что проблема именно в фильтрации по этому полю.
Особое внимание стоит уделить запросам, использующим виртуальные таблицы, особенно внутри соединений. Частая причина тормозов — использование виртуальной таблицы СрезПоследних.
Рассмотрим пример неоптимального запроса из темы на форуме:
ВЫБРАТЬ
Операции.Ссылка,
ВложенныйЗапрос.Статус
ИЗ
Справочник.Операции КАК Операции
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
Статус,
Операция
ИЗ
РегистрСведений.Статусы.СрезПоследних(,)) КАК ВложенныйЗапрос
ПО ВложенныйЗапрос.Операция = Операции.Ссылка
В чем здесь проблема? При каждом обновлении данных динамического списка платформа может пересчитывать СрезПоследних для всего регистра, а не для одной измененной записи. Если регистр сведений содержит миллионы записей, это приводит к колоссальной нагрузке на сервер. Платформа не всегда может эффективно оптимизировать такой запрос.
После диагностики перейдем к исправлению. Начнем с самых простых и эффективных методов.
Это первое, что стоит попробовать, и именно это помогло автору в исходной теме. Штатная утилита «Тестирование и исправление» выполняет несколько важных действий:
Как запустить: Запустите 1С в режиме Конфигуратора, перейдите в меню «Администрирование» -> «Тестирование и исправление». Установите флажки «Реиндексация таблиц информационной базы» и «Пересчет итогов». Для SQL-версии также полезно выполнить «Сжатие таблиц». Важно: перед запуском обязательно сделайте резервную копию базы данных.
В большинстве случаев, когда производительность падает «внезапно, хотя вчера все работало», именно ТиИ или аналогичные процедуры обслуживания на стороне SQL Server (обновление статистики, реорганизация индексов) решают проблему.
Если ТиИ не помогло или дало лишь временный эффект, необходимо оптимизировать сам запрос. Вот несколько подходов:
Включение итогов для регистра сведений. Для периодических регистров сведений можно включить расчет итогов. Платформа будет поддерживать специальные таблицы с заранее рассчитанными последними значениями. Это кардинально ускоряет работу виртуальных таблиц СрезПоследних и СрезПервых. Для этого в свойствах регистра сведений установите свойство Использование итогов в значение Включить и укажите периодичность пересчета.
Замена на прямой запрос к физической таблице. Вместо использования виртуальной таблицы можно написать запрос напрямую к физической таблице регистра, получая максимальный период с помощью вложенного запроса. Этот метод дает больше контроля над планом выполнения.
Денормализация данных. Если актуальный статус требуется очень часто, можно добавить реквизит «Статус» непосредственно в справочник «Операции». Обновлять его можно при записи в регистр сведений или с помощью регламентного задания. Тогда в динамическом списке не потребуется соединение, и данные будут читаться напрямую из основной таблицы, что максимально быстро.
Очистка пользовательских настроек. Иногда причиной могут быть «испорченные» или слишком сложные пользовательские настройки динамического списка (отборы, сортировки). Попробуйте очистить их для пользователя через стандартные функции платформы или удалив запись из хранилища настроек. Это быстрый способ исключить данную причину.
Настройка планов обслуживания на SQL Server. Не полагайтесь только на средства 1С. Настройте на стороне SQL Server регулярные регламентные задания (Maintenance Plans) для обновления статистики и реорганизации/перестроения индексов для самых больших и часто изменяемых таблиц вашей базы. Это обеспечит стабильную производительность в долгосрочной перспективе.
Подведем итог. Зависание динамического списка при записи элемента — это почти всегда признак неэффективного запроса к базе данных. Начните диагностику с простого — выполните Тестирование и исправление. Если проблема не ушла, углубляйтесь в анализ плана запроса, проверяйте индексы и ищите «узкие» места, такие как использование СрезПоследних в соединениях. Системный подход к оптимизации и регулярное обслуживание базы данных помогут избежать подобных проблем в будущем.