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

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

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

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

Что такое индексы и зачем их перестраивать

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

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

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

Когда реиндексация действительно нужна

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

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

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

Как выполнить реиндексацию файловой базы через конфигуратор

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

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

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

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

Реиндексация в клиент-серверном варианте

В клиент-серверной архитектуре таблицы хранятся в СУБД — MS SQL Server, PostgreSQL, Oracle или IBM DB2, — и перестроение индексов выполняется её средствами. Режим «Тестирование и исправление» для серверных баз имеет ограничения, и реиндексацию обычно переносят на уровень СУБД, где она выполняется быстрее и гибче.

В MS SQL Server применяют команды ALTER INDEX ... REBUILD или план обслуживания (Maintenance Plan) с задачей перестроения индексов. В PostgreSQL — команду REINDEX. Перестроение можно совмещать с обновлением статистики: в MS SQL это UPDATE STATISTICS, в PostgreSQL — ANALYZE. Индексы и актуальная статистика вместе дают основной эффект для скорости запросов.

ALTER INDEX ALL ON _Document123 REBUILD;

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

Чем реиндексация отличается от реструктуризации и других проверок

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

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

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

Главный риск — прерывание процедуры на файловой базе. Отключение питания, перезагрузка сервера или принудительное закрытие конфигуратора в середине тестирования может повредить файл 1Cv8.1CD, и тогда потребуется восстановление из копии или утилита chdbfl.exe. Именно поэтому резервная копия перед запуском — обязательный, а не рекомендуемый шаг.

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

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

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

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

Часто задаваемые вопросы