Как оптимизировать базу данных 1С

Медленная работа базы 1С почти никогда не имеет одной причины. Обычно это сочетание факторов: разросшиеся таблицы итогов, отсутствие индексов под реальные запросы, неоптимальные настройки СУБД, устаревшие статистики и фоновые процессы, которые конкурируют за ресурсы с пользователями. Поэтому оптимизация начинается не с «ускорения», а с диагностики — нужно понять, где именно теряется время.

Подход к оптимизации зависит от режима работы базы. Файловая база упирается в скорость диска и блокировки файла, клиент-серверная (MS SQL Server, PostgreSQL) — в настройки СУБД, планы запросов и индексы. Приёмы, эффективные для клиент-серверного варианта, в файловом режиме часто неприменимы, и наоборот.

Ниже разобраны прикладные шаги: как найти узкое место, что сделать на уровне платформы, конфигурации и СУБД, как безопасно сократить объём данных и как убедиться, что оптимизация действительно сработала. Все действия, затрагивающие структуру или данные, выполняются только после резервного копирования.

С чего начать: диагностика узких мест

Оптимизировать вслепую — значит тратить время на то, что не влияет на скорость. Первый шаг — зафиксировать симптомы: какие операции тормозят (проведение документов, отчёты, открытие списков), у всех пользователей или у конкретных, постоянно или в часы пик. Это сразу сужает круг поиска: проблема с отчётом указывает на запросы и индексы, а тормоза при проведении — на блокировки и итоги регистров.

Для клиент-серверного варианта основной инструмент — технологический журнал платформы с фильтром по событиям DBMSSQL/DBPOSTGRS и длительности. Он покажет конкретные запросы, которые выполняются дольше нормы, и контекст их вызова. Параллельно полезно посмотреть счётчики производительности сервера: загрузка CPU, очередь диска, объём свободной памяти.

Для MS SQL Server дополнительно используются динамические административные представления (sys.dm_exec_query_stats, sys.dm_db_index_usage_stats) — они показывают самые дорогие запросы и неиспользуемые индексы. В PostgreSQL аналогичную роль играет расширение pg_stat_statements.

Регламентное обслуживание СУБД

Значительная часть «замедлений» клиент-серверных баз снимается базовым обслуживанием. СУБД строит планы запросов на основе статистики распределения данных; если статистика устарела, оптимизатор выбирает неудачный план, и запрос сканирует миллионы строк вместо чтения по индексу. Обновление статистики — первое, что стоит сделать при внезапном замедлении.

Второй пункт — дефрагментация или перестроение индексов. При интенсивной записи индексы фрагментируются, и чтение становится менее эффективным. Обычно настраивают регламент: перестроение наиболее фрагментированных индексов и обновление статистики — еженедельно или чаще, в нерабочие часы. Точные пороги фрагментации зависят от принятых практик администрирования конкретной СУБД.

Третий аспект — настройки самой базы: размер и рост файлов данных и журнала транзакций, модель восстановления, tempdb для MS SQL, параметры памяти. Автоприрост файлов маленькими порциями и переполненный журнал транзакций — частые скрытые причины просадок производительности.

Индексы и запросы: что проверить в первую очередь

Платформа 1С создаёт индексы автоматически по типовым правилам, но они не покрывают все реальные сценарии. Если отчёт или обработка фильтрует данные по нестандартному сочетанию полей (например, по реквизиту документа без индекса), СУБД вынуждена сканировать таблицу целиком. Признак — запрос, который на копии базы с малым объёмом работает быстро, а на рабочей «зависает».

Для управляемых индексов в конфигураторе используется свойство «Индексировать» у реквизитов и составные индексы с дополнительными полями. Добавлять индекс стоит только под подтверждённый замерами запрос: каждый лишний индекс замедляет запись и увеличивает размер базы. Баланс между скоростью чтения и записи — ключевое ограничение этого приёма.

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

1. 1
   Найдите запрос в технологическом журнале или статистике СУБД и зафиксируйте время выполнения
2. 2
   Получите план запроса средствами СУБД и проверьте, есть ли сканирование больших таблиц
3. 3
   Проверьте, актуальна ли статистика по задействованным таблицам; обновите при необходимости
4. 4
   Определите, какого индекса не хватает, либо перепишите запрос так, чтобы использовался существующий
5. 5
   Повторите замер на рабочем объёме данных и сравните с исходным результатом

Сокращение объёма данных

Даже идеально настроенная база замедляется, когда таблицы разрастаются до десятков и сотен гигабайт. Основные «потребители» места в типовых конфигурациях: журнал регистрации, версии объектов, сохранённые настройки отчётов, незавершённые сеансы обмена, регистры сведений с историей изменений и накопленные итоги за давние периоды.

Журнал регистрации имеет смысл настроить на хранение ограниченного периода или разделить на файлы по датам с последующим удалением старых. Версионирование объектов стоит включать только для действительно важных типов и задавать срок хранения версий. Данные обменов и очереди сообщений нужно регулярно очищать штатными средствами конфигурации.

Для старых учётных данных применяют свёртку базы: остатки переносятся на дату свёртки документами ввода остатков, а документы прошлых лет удаляются. Это радикальная операция — её выполняют на копии, тщательно сверяют остатки по всем разделам учёта и только потом повторяют на рабочей базе.

Настройки платформы и конфигурации

На уровне платформы влияют несколько переключателей. Разделение итогов регистров накопления ускоряет проведение документов в многопользовательском режиме за счёт снижения конкуренции за записи итогов — на крупных базах это один из самых заметных по эффекту шагов. Режим управления блокировками (управляемый вместо автоматического) уменьшает число конфликтов, но требует, чтобы код конфигурации был к нему готов.

Регламентные и фоновые задания стоит проаудировать: типовые конфигурации содержат десятки заданий, часть из которых конкретному предприятию не нужна (например, загрузка курсов валют при моновалютном учёте). Лишние задания отключают, а тяжёлые переносят на ночь. Полный текстовый поиск, если он не используется, тоже разумно отключить — обновление его индекса потребляет ресурсы.

Для файловых баз принципиально важны два момента: база должна лежать на быстром локальном диске (не на сетевом ресурсе), а антивирус должен исключать каталог базы из проверки в реальном времени. Если пользователей больше нескольких человек и база активно растёт, переход на клиент-серверный вариант обычно даёт больший эффект, чем любая точечная настройка.

Файловый или клиент-серверный режим

Файловая база

Подходит для небольшого числа пользователей и умеренного объёма. Ограничения: блокировки всего файла, зависимость от сети и диска, нет тонкой настройки индексов.

Клиент-серверная база (MS SQL / PostgreSQL)

Подходит для десятков пользователей и больших объёмов. Даёт управление индексами, статистикой и параллелизмом, но требует администрирования СУБД и лицензий.

Оптимизация кода и тяжёлых операций

Если тормозит конкретная операция — обработка, отчёт, проведение документа — причина часто в коде. Классические проблемы: запросы внутри цикла, обращение к реквизитам объектов через точку (каждое обращение — отдельный запрос к базе), чтение больших выборок целиком в память, отсутствие транзакций там, где они нужны, и избыточные транзакции там, где не нужны.

Базовые приёмы исправления: вынести запрос из цикла и получать данные пакетно; вместо обхода объектов использовать запрос с выборкой нужных полей; для массовых изменений применять пакетную обработку с промежуточной фиксацией. В отчётах на СКД проверяйте автогенерируемые запросы — наборы данных-объединения и связи наборов часто создают лишнюю нагрузку.

Инструмент для поиска таких мест — замер производительности в конфигураторе: он показывает, какие строки модуля занимают основное время. Оптимизировать стоит только «горячие» участки, подтверждённые замером, а не весь код подряд.

Как проверить результат и не навредить

Любое изменение оценивается повторным замером в сопоставимых условиях: та же операция, тот же объём данных, сопоставимая нагрузка. Полезно зафиксировать «базовую линию» до начала работ — время типовых операций — и сравнивать с ней после каждого шага, а не только в конце.

Косвенные признаки успеха: план запроса перешёл со сканирования на поиск по индексу, исчезли длительные события в технологическом журнале, снизилось число взаимоблокировок, уменьшилась очередь диска в часы пик. Если метрики не изменились — причина не найдена, и нужно возвращаться к диагностике, а не наращивать «железо».

Граница безопасной самостоятельной работы проходит там, где начинаются изменения структуры, массовое удаление данных и тонкая настройка СУБД. Эти операции выполняются на копии, с резервной копией и планом отката. Если база критична для бизнеса, разумно привлечь специалиста по администрированию 1С и СУБД хотя бы для первичной диагностики.

Контрольные точки

Как проверить результат

Время типовой операции до и после

Норма

Время сократилось при том же объёме данных

Тревожный признак

Время не изменилось или выросло — причина не устранена

План проблемного запроса

Норма

Используется поиск по индексу (index seek)

Тревожный признак

Сканирование таблицы (table scan) на большом объёме

Технологический журнал

Норма

Длительные запросы и взаимоблокировки исчезли

Тревожный признак

Те же события повторяются с прежней длительностью

Размер базы и прирост

Норма

Рост замедлился после чистки служебных данных

Тревожный признак

База растёт прежними темпами — не найден источник роста

Частые вопросы

С чего начать, если база 1С внезапно стала медленной?

Сначала проверьте простые внешние причины: свободное место на дисках сервера, загрузку CPU и памяти, работу антивируса. Затем обновите статистику в СУБД — внезапное замедление без роста объёма данных чаще всего связано именно с устаревшей статистикой и неудачным планом запроса.

Поможет ли увеличение оперативной памяти серверу?

Только если проблема действительно в нехватке памяти: это видно по активному использованию файла подкачки и низкому проценту попаданий в буферный кэш СУБД. Если узкое место — запросы без индексов или блокировки, добавление памяти эффекта не даст.

Как часто нужно обновлять статистику и перестраивать индексы?

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

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

Частично: перенос базы на SSD, исключение каталога из антивируса, чистка журнала регистрации и отключение лишних фоновых заданий дают заметный эффект. Но при росте числа пользователей и объёма данных файловый режим упирается в архитектурные ограничения, и переход на СУБД становится единственным системным решением.

Опасно ли включать разделение итогов регистров?

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

Как понять, что пора делать свёртку базы?

Признаки: база занимает сотни гигабайт, регламентные операции и резервное копирование длятся часами, отчёты за текущий период тормозят из-за объёма исторических данных, а доступ к документам прошлых лет нужен редко. Если историю требуется хранить, альтернатива — вынос старых периодов в отдельную архивную базу.