Реиндексация таблиц базы 1С 8.3: когда и как выполнять

Перестроить индексы можно двумя путями. Для файловой базы и небольшой клиент-серверной — через Конфигуратор: Администрирование → Тестирование и исправление, флажок Реиндексация таблиц информационной базы. Для крупной базы на SQL — средствами самой СУБД: ALTER INDEX ... REBUILD в MS SQL или REINDEX в PostgreSQL.

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

Ниже — когда перестроение действительно нужно, как подготовить базу, чем выполнить на платформе и на уровне СУБД, как поставить обслуживание на автомат и как убедиться, что стало лучше.

Когда базе 1С нужна реиндексация

Перестроение индексов — не плановая обязанность на каждый день, а ответ на конкретные симптомы. Поводы задуматься:

• 🐢 Отчёты и списки, которые раньше открывались за секунды, стали «думать» десятки секунд.
• 📄 Проведение и перепроведение документов заметно затянулось без роста объёма операций.
• 📈 База сильно выросла: активный ввод, регулярные загрузки из обменов, массовые перепроведения.
• 🔄 После крупной реструктуризации (обновление с изменением структуры метаданных, свёртка базы).
• ⚠️ В технологическом журнале или логах СУБД видны долгие запросы с полным сканированием таблиц.

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

Что сделать до запуска перестроения

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

1. Сделайте резервную копию. Для файловой базы — копия файла 1Cv8.1CD при закрытой базе. Для клиент-серверной — штатный бэкап средствами СУБД (BACKUP DATABASE в MS SQL, pg_dump или базовая копия в PostgreSQL).
2. Выберите окно. Ночь или выходные — время, когда в базе нет пользователей. Реиндексация крупной базы может идти от десятков минут до нескольких часов.
3. Выгоните пользователей. Реиндексация через Конфигуратор требует монопольного доступа — платформа не даст запустить её, пока в базе кто-то работает. Завершите активные сеансы через консоль администрирования кластера или дайте пользователям корректно выйти.
4. Проверьте место на диске. При перестроении СУБД временно держит и старую, и новую версию индекса. Для MS SQL с опцией SORT_IN_TEMPDB запас нужен и в tempdb.
5. Отключите на время окна фоновые операции. Расписание обменов, выгрузок и других заданий, которые сами лезут в базу, лучше приостановить — иначе они и займут таблицы, и не дадут получить монопольный доступ.

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

Реиндексация средствами платформы 1С

Встроенный механизм — универсальный: работает и для файловой, и для клиент-серверной базы, не требует знания SQL.

Откройте Конфигуратор нужной информационной базы и зайдите в Администрирование → Тестирование и исправление. В окне несколько проверок — для перестроения индексов нужен флажок Реиндексация таблиц информационной базы. Остальные галочки (проверка логической и ссылочной целостности, пересчёт итогов) ставьте только если решаете соответствующую задачу: каждая удлиняет процесс.

Пошагово:

1. Снимите все флажки, кроме Реиндексация таблиц информационной базы.
2. В блоке режима выберите Тестирование и исправление (режим Только тестирование индексы не перестраивает, а лишь проверяет).
3. Запустите кнопкой выполнения проверки.
4. Дождитесь завершения — прогресс виден в служебных сообщениях. Прерывать нельзя.

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

Перестроение индексов на уровне СУБД

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

MS SQL Server. Перестроение одного или всех индексов таблицы:

-- полное перестроение всех индексов таблицы
ALTER INDEX ALL ON [_Reference123] REBUILD;

-- более лёгкая дефрагментация без полной пересборки
ALTER INDEX ALL ON [_Reference123] REORGANIZE;

REBUILD пересоздаёт индекс целиком и обновляет статистику по нему, но на время работы (без Enterprise-опции ONLINE) блокирует таблицу. REORGANIZE работает в онлайне, грузит сервер меньше, но помогает только при умеренной фрагментации. Общепринятый ориентир по полю avg_fragmentation_in_percent: до 5 % — ничего не делать, 5–30 % — REORGANIZE, выше 30 % — REBUILD.

Имена таблиц 1С в СУБД платформа генерирует сама, и человеку они мало о чём говорят: регистры накопления лежат в таблицах с префиксом _AccumRg, регистры сведений — _InfoRg, документы — _Document, справочники — _Reference, к ним добавлены числовые идентификаторы. Поэтому точечно перестраивать по именам неудобно — на практике либо обслуживают всю базу планом целиком, либо отбирают таблицы по фрагментации запросом к системным представлениям, а не вручную по названиям.

Для 1С на MS SQL в регламент обычно включают связку: перестроение/дефрагментацию индексов → обновление статистики → очистку процедурного кэша, чтобы оптимизатор пересобрал планы под свежие индексы.

-- обновление статистики по всей базе
EXEC sp_updatestats;

-- сброс кэша планов (выполнять в ночном окне)
DBCC FREEPROCCACHE;

PostgreSQL. Здесь перестроение индексов — команда REINDEX, а за актуальность статистики и очистку «мусорных» версий строк отвечают VACUUM и ANALYZE:

-- перестроить все индексы базы
REINDEX DATABASE mybase;

-- перестроить индексы одной таблицы
REINDEX TABLE _reference123;

-- собрать статистику и освободить место
VACUUM ANALYZE;

Для PostgreSQL важен настроенный autovacuum: если он отстаёт, таблицы «распухают» мёртвыми строками, и никакая разовая реиндексация надолго не спасёт. На активных базах 1С параметры автоочистки обычно делают агрессивнее стандартных.

Регламентное обслуживание вместо ручного запуска

Разовое перестроение решает проблему на сегодня. Чтобы база не замедлялась снова, обслуживание ставят на расписание.

MS SQL Server. В SQL Server Management Studio есть Management → Maintenance Plans. Соберите план из задач:

• Rebuild Index или Reorganize Index — перестроение индексов;
• Update Statistics — обновление статистики;
• Backup Database — резервная копия перед обслуживанием.

План ставят на ночной запуск через SQL Server Agent. Частоту подбирают по нагрузке: для активных баз 1С — обычно раз в сутки обновление статистики и раз в неделю полное перестроение индексов.

PostgreSQL. Регулярный VACUUM ANALYZE закрывает автовакуум, а периодический REINDEX сильно фрагментированных таблиц ставят отдельным заданием cron на ночь. Прямо внутри базы расписание не хранится — задачи выполняет планировщик операционной системы.

Встроенные регламентные задания 1С для перестроения индексов не предназначены: они про прикладную логику (пересчёт итогов, обновление агрегатов), а не про физическую структуру таблиц СУБД. Поэтому обслуживание индексов настраивают именно на стороне сервера базы данных.

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

После перестроения стоит убедиться, что фрагментация действительно снизилась, а не просто «прошла операция без ошибок».

В MS SQL фрагментацию показывает системное представление:

SELECT OBJECT_NAME(ips.object_id) AS table_name,
       ips.index_id,
       ips.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') AS ips
WHERE ips.avg_fragmentation_in_percent > 10
ORDER BY ips.avg_fragmentation_in_percent DESC;

После корректного перестроения значения по крупным таблицам должны упасть к единицам процентов. В PostgreSQL прямого аналога нет — ориентируются на размер таблиц и индексов (pg_total_relation_size, pg_relation_size) до и после и на скорость проблемных запросов. Заметное сокращение размера индекса после REINDEX как раз и говорит, что фрагментация была высокой; если размер почти не изменился, перестраивать его регулярно смысла нет.

Главный критерий — субъективный, но честный: откройте те самые отчёты и документы, которые тормозили, и сравните время. Если разницы нет, дело было не в индексах.

Если перестроение индексов приходится делать часто, а эффект держится недолго — это сигнал глубже посмотреть на настройки СУБД, автовакуум (для PostgreSQL) и регламент обновления статистики. Разовая реиндексация лечит симптом, а стабильную скорость даёт налаженное регулярное обслуживание.

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