Как ускорить работу журнала документов при большом объеме данных и избежать зависаний при отборах

← На главную

При эксплуатации систем 1С на протяжении многих лет (в нашем примере — 7 лет) базы данных неизбежно разрастаются. Когда количество записей в журнале документов, например, РеализацияТоваровУслуг, переваливает за 500 000, пользователи начинают жаловаться на «подвисания» при попытке установить фильтр или просто пролистать список. Особенно остро эта проблема проявляется в конфигурациях на обычных формах, таких как «Управление торговлей 10.3».

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

Почему стандартные журналы начинают тормозить

Проанализируем ситуацию: когда пользователь открывает журнал без фильтров, система обычно считывает последние записи. Но как только устанавливается отбор (например, по контрагенту или складу), СУБД (SQL Server) должна найти подходящие записи среди сотен тысяч строк. Если соответствующий индекс отсутствует или неэффективен, происходит операция TABLE SCAN — полное сканирование таблицы, что и вызывает длительное ожидание.

Важным фактором является так называемая селективность индекса. Если на одного контрагента (например, «Розничный покупатель») приходится 40% всех документов (200 000 из 500 000), стандартный поиск по индексу может перестать работать. SQL-сервер решит, что проще прочитать всю таблицу целиком, чем использовать индекс. Это называется «точкой перелома» (Tipping Point).

Стоит ли создавать отдельный документ Реализация_Архив

Рассмотрим идею автора темы: перенести старые документы в новый объект РеализацияТоваровУслуг_Архив. На первый взгляд, это разгрузит основную таблицу. Однако проанализируем «подводные камни»:

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

Вывод: Создание архивного документа — это крайняя мера, которая создает больше проблем, чем решает. Лучше использовать проверенные методы оптимизации.

Метод 1: Ограничение периода выборки по умолчанию

Самый простой и эффективный способ ускорить работу пользователя — не давать ему открывать «всю историю» сразу. Если установить в коде формы журнала отбор по умолчанию за последние 1–2 месяца, объем обрабатываемых данных сократится в десятки раз.

Разберем пример установки программного фильтра при открытии формы:


Процедура ПриОткрытии()
    // Установим период по умолчанию: начало текущего месяца
    Если Не ЗначениеЗаполнено(ДатаНачала) Тогда
        ДатаНачала = НачалоМесяца(ТекущаяДата());
        ЭлементыФормы.ДокументСписок.НастройкаОтбора.Дата.Доступность = Истина;
        ЭлементыФормы.ДокументСписок.НастройкаОтбора.Дата.ЗначениеС = ДатаНачала;
        ЭлементыФормы.ДокументСписок.НастройкаОтбора.Дата.Использование = Истина;
    КонецЕсли;
КонецПроцедуры

Это заставит SQL-сервер выполнять INDEX SEEK по полю даты, что отрабатывает мгновенно даже на миллионных таблицах.

Метод 2: Оптимизация индексов и статистики SQL

Если отбор по конкретному контрагенту (например, «Розничный покупатель») занимает более минуты, это явный признак проблем с индексами. Выясним причину через консоль SQL или замер производительности 1С.

Что нужно сделать:

Убедитесь, что для реквизитов, по которым часто идут отборы (Контрагент, Склад, Организация), в конфигураторе установлено свойство «Индексировать» (или «Индексировать с доп. упорядочиванием»).
Выполните регламентные задания на уровне SQL-сервера: переиндексацию и обновление статистики. Статистика крайне важна для оптимизатора запросов, чтобы он понимал распределение данных (сколько документов приходится на «Розничного покупателя»).
В некоторых случаях помогает создание «покрывающего» индекса непосредственно в SQL Management Studio, но помните, что при обновлении конфигурации 1С может пересоздать таблицы и удалить ваши кастомные индексы.

Метод 3: Использование «теневого» регистра сведений

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

Создаем индексированный Регистр сведений (например, БыстрыйПоискДокументов).
В ресурсах или измерениях храним только критичные данные: СсылкаНаДокумент, Дата, Контрагент, Сумма.
При проведении или записи документа данные в регистре обновляются (через подписки на события).
Создаем форму списка, которая строится на базе этого регистра. Поиск по узкой таблице регистра сведений всегда будет быстрее, чем по широкой таблице документов.

Метод 4: Правильная обрезка базы (Sverka) в условиях РИБ

Обрезка базы — наиболее радикальный, но правильный путь удаления данных старше 3–5 лет. Однако наличие распределенной информационной базы (РИБ) усложняет процесс. Рассмотрим, как избежать гигантских файлов обмена:

Алгоритм безопасной обрезки:

Синхронизируйте все узлы РИБ до полной идентичности.
Временно отключите регистрацию изменений для плана обмена на период удаления. Это предотвратит попадание миллионов записей об удалении в таблицу _MessageNo.
Проведите обрезку (удаление старых документов и очистку движений) в главном узле.
Выполните аналогичную операцию удаления во всех периферийных узлах локально (используя ту же дату среза).
Включите регистрацию изменений обратно.
Выполните операцию Shrink (сжатие) базы данных на уровне SQL, чтобы вернуть освободившееся место операционной системе.

Метод 5: Технологические хитрости СУБД

Если вы используете SQL Server Enterprise, можно рассмотреть секционирование таблиц (Table Partitioning). Вы можете физически разнести данные таблицы документов по годам в разные файлы на диске. Для платформы 1С это будет выглядеть как одна таблица, но SQL будет обращаться только к секции за 2023–2024 год, полностью игнорируя старые данные при запросах с фильтром по дате.

Также проанализируем план запроса. Если вы видите оператор Key Lookup, это означает, что индекс помогает найти строку, но затем SQL приходится лезть в основную таблицу за недостающими полями. Уменьшение количества колонок в списке журнала может существенно ускорить выборку.

Резюме

Посмотрим на итоги: для решения проблемы «тормозов» журнала на 500 000 записей не нужно плодить новые сущности вроде «Архивных документов». Достаточно внедрить обязательный фильтр по периоду, проверить индексы по контрагентам и запланировать регламентную обрезку базы с предварительным отключением регистрации в РИБ. Эти меры позволят системе работать стабильно даже при постоянном росте объема данных.