Реиндексация таблиц информационной базы 1С: что это в SQL и как её выполнить

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

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

Важно понимать двойственность термина: в экосистеме 1С «реиндексация» может означать как штатную операцию в конфигураторе (пункт «Тестирование и исправление»), так и прямое перестроение индексов средствами SQL Server через команды T-SQL. Оба подхода решают одну задачу, но различаются по механизму, скорости и рискам. Ниже разобраны оба варианта, условия их применения и способы проверки результата.

Что такое индексы и почему они фрагментируются в базе 1С

Индекс в SQL Server — это структура данных (B-дерево), которая позволяет быстро находить строки по значениям ключевых полей без полного сканирования таблицы. В базе 1С индексы создаются автоматически по метаданным конфигурации: по ссылке документа, по измерениям регистра, по периоду записей. Например, у регистра накопления есть индекс по регистратору, а у справочника — по коду и наименованию.

Фрагментация возникает из-за постоянных операций INSERT, UPDATE и DELETE. Когда строка удаляется, на странице индекса остаётся «дырка»; когда вставляется новая строка и страница заполнена, происходит разделение страницы (page split) — часть записей переносится на новую страницу, которая физически может располагаться далеко от исходной. В результате логический порядок индекса перестаёт совпадать с физическим расположением данных на диске.

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

Как понять, что базе нужна реиндексация

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

Точный способ оценки — запрос к системным представлениям SQL Server, который показывает процент фрагментации каждого индекса. Общепринятая практика: при фрагментации до 10% ничего делать не нужно, от 10% до 30% достаточно реорганизации индекса (REORGANIZE), свыше 30% рекомендуется полное перестроение (REBUILD).

SELECT OBJECT_NAME(ips.object_id) AS TableName, i.name AS IndexName, ips.avg_fragmentation_in_percent FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ips JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id WHERE ips.avg_fragmentation_in_percent > 10 ORDER BY ips.avg_fragmentation_in_percent DESC;

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

Реиндексация через конфигуратор 1С: плюсы и порядок действий

Штатный путь — обработка «Тестирование и исправление» в конфигураторе. В списке проверок нужно отметить пункт «Реиндексация таблиц информационной базы» и запустить выполнение. Конфигуратор пройдёт по всем таблицам, соответствующим объектам метаданных, и перестроит их индексы средствами СУБД.

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

1. 1
   Сделайте резервную копию базы средствами СУБД или выгрузку в dt
2. 2
   Завершите сеансы всех пользователей и отключите регламентные задания
3. 3
   Откройте конфигуратор в монопольном режиме
4. 4
   Перейдите: Администрирование → Тестирование и исправление
5. 5
   Отметьте пункт «Реиндексация таблиц информационной базы» и нажмите «Выполнить»
6. 6
   Дождитесь завершения, проверьте журнал и запустите базу в рабочем режиме

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

Реиндексация напрямую в SQL Server: команды и сценарии

В клиент-серверном варианте администратор может перестроить индексы напрямую в SQL Server, минуя конфигуратор. Это быстрее для точечных работ: можно обслужить только самые фрагментированные таблицы, а не всю базу. Основные команды — ALTER INDEX REBUILD (полное перестроение) и ALTER INDEX REORGANIZE (облегчённая реорганизация).

ALTER INDEX ALL ON dbo._Document123 REBUILD WITH (ONLINE = ON, FILLFACTOR = 90);

Опция ONLINE = ON (доступна в редакции Enterprise) позволяет перестраивать индекс без полной блокировки таблицы — пользователи продолжают работать. Параметр FILLFACTOR задаёт процент заполнения страниц индекса; для таблиц 1С с активной вставкой записей значение около 90 снижает скорость повторной фрагментации, оставляя место под новые строки.

Для регулярного обслуживания удобно оформить скрипт как задание SQL Server Agent, которое ночью проверяет фрагментацию и выбирает REBUILD или REORGANIZE по порогам. Готовые проверенные скрипты обслуживания индексов (например, широко известное решение Ola Hallengren) используются администраторами как стандарт де-факто и избавляют от написания собственной логики.

Реиндексация и обновление статистики: в чём разница

Частая ошибка — путать реиндексацию с обновлением статистики. Статистика — это сведения о распределении значений в колонках, по которым оптимизатор SQL Server выбирает план запроса. Устаревшая статистика приводит к неоптимальным планам даже при идеальных индексах. Полное перестроение индекса (REBUILD) обновляет статистику автоматически, а REORGANIZE — нет.

Поэтому если после реорганизации индексов запросы всё ещё медленные, следующий шаг — принудительное обновление статистики командой UPDATE STATISTICS или процедурой sp_updatestats. В регламентных работах по базам 1С обе операции обычно идут парой: сначала обслуживание индексов, затем обновление статистики по ключевым таблицам.

Риски, ограничения и типичные ошибки

Главный риск реиндексации — блокировки. REBUILD без опции ONLINE монопольно блокирует таблицу: все запросы к ней встают в очередь, а в 1С это выглядит как зависание сеансов с последующими ошибками превышения времени ожидания. Вторая опасность — рост журнала транзакций: перестроение большого индекса генерирует значительный объём лога, и при нехватке места на диске с файлом журнала операция аварийно завершится.

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

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

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

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

FAQ: частые вопросы о реиндексации баз 1С