Администрирование · 12 мин
Как ускорить работу 1С на SQL-сервере
Практические способы ускорить 1С на SQL Server: настройки СУБД, индексы, tempdb, обновление статистики, оптимизация запросов и планов обслуживания базы.
Медленная работа 1С в клиент-серверном варианте почти всегда упирается в связку «платформа 1С + СУБД». Проведение документов занимает минуты вместо секунд, отчёты формируются по полчаса, а пользователи жалуются на подвисания интерфейса. В большинстве случаев причина — не «тяжёлая конфигурация», а неправильно настроенный SQL Server, фрагментированные индексы или устаревшая статистика.
Ускорение 1С на SQL складывается из нескольких уровней: настройки самой СУБД, обслуживание базы (индексы, статистика), анализ тяжёлых запросов и оптимизация кода конфигурации. Менять что-то «вслепую» опасно: неправильное значение max degree of parallelism или отключённое автообновление статистики могут замедлить систему сильнее, чем было.
Ниже — конкретные действия, которые администратор 1С может выполнить самостоятельно, с признаками результата и границами, где лучше остановиться и привлечь специалиста по MS SQL.
Диагностика: что именно тормозит
Прежде чем что-то менять, нужно понять, где узкое место. Один и тот же симптом — «всё медленно» — может означать нехватку памяти на сервере СУБД, блокировки, устаревшую статистику или один неоптимальный запрос в отчёте.
Первичные признаки: если тормозят все операции равномерно — вероятны проблемы с дисковой подсистемой, памятью или общими настройками SQL Server. Если медленно работают конкретные документы или отчёты — ищите проблему в конкретных запросах и планах выполнения. Если система «замирает» периодически — проверяйте блокировки и взаимоблокировки.
Инструменты диагностики: технологический журнал 1С (события DBMSSQL с длительностью), динамические административные представления SQL Server (dm_exec_query_stats, dm_os_wait_stats), счётчики производительности сервера (загрузка дисков, память, ожидания). Для блокировок — событие TLOCK технологического журнала и представление dm_tran_locks.
Проверьте память, диски, настройки SQL Server и tempdb
Снимите план выполнения запроса, проверьте индексы и статистику
Включите сбор TLOCK в технологическом журнале, проверьте уровень изоляции
Проверьте фрагментацию индексов и дату последнего обновления статистики
Настройка SQL Server под 1С
Стандартная установка SQL Server «по умолчанию» плохо подходит для 1С. Есть несколько параметров, которые рекомендуется выставить сразу после развёртывания сервера.
Max server memory. Ограничьте память SQL Server, оставив операционной системе и серверу 1С (если он на той же машине) достаточный объём. Без ограничения SQL Server может занять почти всю память и вызвать подкачку. Max degree of parallelism (MAXDOP). Для баз 1С обычно рекомендуется значение 1, так как параллельные планы часто провоцируют ожидания CXPACKET и блокировки на характерной для 1С нагрузке. Tempdb. Создайте несколько файлов tempdb (обычно по числу физических ядер, но не более 8) одинакового размера с одинаковым авторасширением — 1С активно использует временные таблицы.
Также проверьте: модель восстановления базы (для большинства баз 1С достаточно Simple, если нет требований к point-in-time восстановлению), автоувеличение файлов данных и журнала (задавайте фиксированным приращением в мегабайтах, а не в процентах), размещение журнала транзакций и файлов данных на разных физических дисках при возможности.
Обслуживание базы: индексы и статистика
Самая частая причина постепенной деградации производительности — фрагментация индексов и устаревшая статистика. SQL Server строит план запроса на основе статистики распределения данных; если статистика устарела, оптимизатор выбирает плохой план, и запрос вместо миллисекунд выполняется секундами.
Настройте регулярный план обслуживания: обновление статистики — ежедневно или хотя бы несколько раз в неделю, реорганизация или перестроение индексов — по расписанию в нерабочее время. Перестроение (rebuild) при фрагментации выше ~30%, реорганизация (reorganize) при умеренной фрагментации. Для больших баз полный rebuild всех индексов может не успеть выполниться за ночь — тогда обрабатывайте индексы выборочно, начиная с самых фрагментированных и самых больших таблиц (регистры накопления, регистры сведений, таблицы документов).
-- Проверка фрагментации индексов базы
SELECT OBJECT_NAME(s.object_id) AS TableName, i.name AS IndexName, s.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') s
JOIN sys.indexes i ON s.object_id = i.object_id AND s.index_id = i.index_id
WHERE s.avg_fragmentation_in_percent > 10
ORDER BY s.avg_fragmentation_in_percent DESC;Признак результата: после обновления статистики и дефрагментации типовые операции (проведение документов, открытие списков) должны ускориться заметно — часто в разы. Если ускорения нет, проблема не в обслуживании, а в запросах или железе.
Поиск и оптимизация тяжёлых запросов
Когда сервер настроен и база обслуживается, оставшиеся тормоза — почти всегда конкретные запросы. Включите в технологическом журнале 1С сбор событий DBMSSQL с длительностью, например, от 1000 мс, и соберите лог за период типичной нагрузки. Из лога возьмите текст запроса и контекст (какой объект конфигурации его инициировал).
Дальше запрос анализируется в SQL Server Management Studio с включённым фактическим планом выполнения. Типичные проблемы: сканирование больших таблиц вместо поиска по индексу (Index Scan вместо Index Seek), соединение по неиндексированным полям, неявные преобразования типов, выборка лишних полей и строк. Часто помогает создание недостающего индекса — но в базе 1С добавлять индексы напрямую в СУБД нельзя: индекс нужно добавить средствами конфигуратора (индексы у реквизитов, измерений, критерии отбора), иначе при обновлении конфигурации возникнут рассинхронизация и ошибки.
Оптимизация на стороне конфигурации 1С
Часть проблем решается только в коде. Классические источники медленных запросов в 1С: соединения с виртуальными таблицами без отборов, вложенные запросы вместо временных таблиц, соединение с таблицей «Итоги» без ограничения периода, использование функций в условиях (запрос теряет возможность использовать индекс), выборка «ВЫБРАТЬ *» с последующим чтением пары полей.
Практические приёмы: помещайте отборы во временные таблицы и индексируйте их; накладывайте параметры на виртуальные таблицы регистров (период, отборы по измерениям); не соединяйтесь с полными таблицами регистров, когда достаточно виртуальной таблицы остатков или оборотов; избегайте запросов в цикле — заменяйте одним запросом с группировкой. Для проверки используйте консоль запросов с замером времени и сравнение планов до и после изменения.
Самый большой выигрыш обычно даёт не тюнинг сервера, а переписывание двух-трёх самых тяжёлых запросов, которые выполняются чаще всего. Начинайте с топа по суммарной длительности из технологического журнала, а не с самого медленного единичного отчёта.
Оборудование и инфраструктура
Никакая настройка не компенсирует слабое железо. Критичные компоненты для связки 1С + SQL: быстрые диски (SSD/NVMe для файлов данных и особенно журнала транзакций), достаточный объём оперативной памяти (буферный пул SQL Server должен вмещать активную часть базы), стабильная сеть между сервером 1С и сервером СУБД — желательно размещать их на одной машине или в одном сегменте с минимальными задержками.
Проверьте очевидные вещи: антивирус не должен сканировать каталоги с файлами базы и журналами SQL Server (добавьте исключения), план электропитания сервера — «Высокая производительность», диски не заполнены более чем на ~85%. Файловый режим работы базы по сети — отдельная история: если база ещё в файловом варианте и тормозит у нескольких пользователей, переход на клиент-серверный режим часто даёт больший эффект, чем любая оптимизация.
Как выбрать действие
Контроль результата и регулярный регламент
Любое изменение должно завершаться замером: время выполнения типовых операций до и после. Зафиксируйте базовые показатели — время проведения типового документа, время формирования ключевых отчётов, длительность регламентных операций. Это позволит объективно оценить эффект и заметить деградацию в будущем.
Минимальный регулярный регламент для базы 1С на SQL: ежедневно — резервное копирование и обновление статистики; еженедельно — дефрагментация индексов по степени фрагментации; ежемесячно — контроль размера базы и журнала, проверка целостности (DBCC CHECKDB на копии или в нерабочее время), анализ топа тяжёлых запросов. Без такого регламента ускорение будет временным: база деградирует снова через недели или месяцы.
Как проверить результат
Заметно сократилось и стабильно в течение дня
Ускорение есть только сразу после обслуживания, затем деградация — ищите проблему в запросах
Ниже 10–15% у ключевых таблиц
Быстро возвращается выше 30% — проверьте расписание обслуживания и отсутствие shrink
Свежая, обновляется по расписанию
Статистика недельной и старше давности — планы запросов неактуальны
Нет доминирующих ожиданий CXPACKET, PAGEIOLATCH, LCK
Один тип ожиданий доминирует — работайте с конкретной причиной
Что важно запомнить
Ускорение 1С на SQL — это цикл: диагностика, настройка сервера, обслуживание индексов и статистики, оптимизация тяжёлых запросов, контроль результата. Разовые действия без регулярного регламента дают временный эффект. Все изменения выполняйте на копии и с замерами до и после.
Частые вопросы
Можно ли добавить индекс в базу 1С напрямую через SQL Server?
Нет. Структура базы должна соответствовать метаданным конфигурации. Индекс, созданный в обход конфигуратора, приведёт к рассинхронизации и ошибкам при обновлении. Добавляйте индексы средствами платформы: у реквизитов и измерений, в критериях отбора, через свойство «Индексировать».
Какое значение MAXDOP выбрать для базы 1С?
Чаще всего рекомендуется 1 — это исключает параллельные планы, которые на характерной для 1С нагрузке вызывают ожидания и блокировки. На очень больших базах с тяжёлыми аналитическими отчётами иногда экспериментируют с малыми значениями, но любое отклонение от 1 нужно проверять замерами.
Поможет ли ускорению переход на более мощный сервер?
Только если узкое место — железо: перегруженные диски, нехватка памяти. Если проблема в плохих запросах или устаревшей статистике, новый сервер даст лишь кратковременное улучшение. Сначала выполните диагностику и обслуживание, потом принимайте решение об апгрейде.
Как часто нужно перестраивать индексы?
Зависит от интенсивности изменения данных. Ориентир — степень фрагментации: rebuild при значениях выше ~30%, reorganize при умеренной фрагментации. Для активно изменяемых баз это обычно еженедельная операция в нерабочее время, для крупных таблиц — по факту фрагментации.
Влияет ли режим блокировок в 1С на скорость?
Да. Автоматический режим блокировок чаще приводит к избыточным блокировкам и взаимоблокировкам. Управляемый режим (по умолчанию в современных конфигурациях) позволяет точнее управлять конкурентным доступом. Перевод старой конфигурации на управляемые блокировки — отдельная задача, требующая анализа кода.
Нужен ли shrink базы после удаления большого объёма данных?
Разовый shrink после массового удаления допустим, но делать его регулярным нельзя: сжатие сильно фрагментирует индексы. После shrink обязательно выполните перестроение индексов. Лучше контролировать рост базы регламентными чистками данных, чем постоянно сжимать файлы.