Администрирование · 11 мин
Реиндексация таблиц в 1С: что это и как выполнить правильно
Что такое реиндексация таблиц в 1С, когда она нужна, как запустить её в конфигураторе и на SQL Server, риски, проверка результата и типичные ошибки.
Реиндексация таблиц в 1С — это процедура перестроения индексов базы данных, при которой платформа удаляет существующие индексы и создаёт их заново. Индексы — это вспомогательные структуры, которые позволяют быстро находить записи в таблицах без полного перебора данных. Со временем, по мере ввода, изменения и удаления документов, индексы фрагментируются, и поиск по ним замедляется.
Косвенные признаки того, что базе требуется реиндексация: отчёты, которые раньше формировались за секунды, теперь «думают» минутами; проведение документов замедлилось; поиск по спискам стал заметно медленнее при том, что объём данных вырос незначительно. Эти симптомы не всегда означают проблему с индексами — причиной может быть и нехватка ресурсов сервера, и блокировки, и устаревшая статистика, — но реиндексация входит в стандартный набор регламентных операций.
Важно понимать: реиндексация не исправляет логические ошибки в данных и не лечит «битые» ссылки. Это профилактическая операция по оптимизации скорости доступа к данным. Для проверки целостности данных существуют другие механизмы — тестирование и исправление с соответствующими режимами проверки ссылочной и логической целостности.
Как устроены индексы и почему они деградируют
Каждая таблица данных 1С (документы, регистры, справочники) имеет один или несколько индексов. Платформа создаёт их автоматически на основе структуры метаданных: по номеру и дате документа, по измерениям регистра, по иерархии справочника. Разработчик может добавить собственные индексы через свойства реквизитов и измерений.
При активной работе пользователей записи постоянно добавляются, изменяются и удаляются. Страницы индекса заполняются неравномерно, появляются «пустоты», логический порядок страниц перестаёт совпадать с физическим — это и есть фрагментация. Чем выше фрагментация, тем больше операций чтения требуется для выполнения запроса.
Реиндексация перестраивает индекс с нуля: страницы уплотняются, порядок восстанавливается, структура становится оптимальной. Дополнительно в клиент-серверном варианте полезно обновлять статистику — данные о распределении значений, которые оптимизатор запросов СУБД использует для выбора плана выполнения.
Когда реиндексация действительно нужна
Не существует универсального расписания, подходящего всем базам. Частота зависит от интенсивности изменения данных: база с сотнями документов в день фрагментируется быстрее, чем архивная база, куда заходят раз в месяц. Для активно используемых баз реиндексацию обычно включают в регламентное обслуживание с периодичностью от раза в неделю до раза в месяц.
Конкретные ситуации, когда процедура оправдана внепланово:
- заметное замедление отчётов, проведения документов и динамических списков без роста нагрузки;
- массовая загрузка или удаление данных (миграция, свёртка базы, загрузка из внешних источников);
- после восстановления базы из копии или переезда на другой сервер;
- обновление конфигурации с изменением структуры индексов.
Сравните время формирования типового отчёта с прежними значениями
Запланируйте реиндексацию после завершения загрузки
Нужны проверки логической и ссылочной целостности
Проверьте ресурсы сервера, блокировки, обновление статистики
Реиндексация в файловой базе через конфигуратор
В файловом варианте работы реиндексация выполняется штатным инструментом «Тестирование и исправление». Процедура требует монопольного доступа: все пользователи должны выйти из базы, фоновые задания — завершиться.
- 1Сделайте резервную копию: скопируйте файл 1Cv8.1CD или выполните выгрузку в dt через конфигуратор
- 2Завершите работу всех пользователей и убедитесь, что база не открыта в других сеансах
- 3Откройте базу в конфигураторе
- 4Перейдите в меню «Администрирование» → «Тестирование и исправление»
- 5Отметьте только пункт «Реиндексация таблиц информационной базы», остальные проверки оставьте выключенными, если они не нужны
- 6Выберите режим «Тестирование и исправление» и нажмите «Выполнить»
- 7Дождитесь окончания и проверьте отсутствие ошибок в окне сообщений
Длительность процедуры зависит от размера базы и скорости дисковой подсистемы: от нескольких минут для небольшой базы до часов для объёмной. Прерывать процесс нельзя — это может оставить базу в повреждённом состоянии, поэтому резервная копия перед запуском обязательна.
Альтернатива для файловой базы — запуск конфигуратора из командной строки с параметрами пакетного режима. Это удобно для автоматизации по расписанию через планировщик задач.
"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F"D:\Bases\MyBase" /N"Администратор" /P"пароль" /IBTestAndRepair -ReindexРеиндексация в клиент-серверном варианте
В клиент-серверной архитектуре (MS SQL Server, PostgreSQL и другие поддерживаемые СУБД) индексы хранятся и обслуживаются средствами самой СУБД. Инструмент «Тестирование и исправление» для таких баз применять не рекомендуется — он выполняется через платформу и работает существенно медленнее штатных механизмов сервера баз данных.
Для MS SQL Server стандартный подход — план обслуживания (maintenance plan) или скрипт, который анализирует фрагментацию индексов и в зависимости от её уровня выполняет либо реорганизацию (ALTER INDEX REORGANIZE — лёгкая операция, работает в сети), либо полное перестроение (ALTER INDEX REBUILD — тяжёлая, в некоторых редакциях требует блокировок). Обычно вместе с этим обновляют статистику.
Для PostgreSQL аналогичные задачи решают команды REINDEX и VACUUM ANALYZE. Конкретные пороги фрагментации и расписание подбираются под нагрузку конкретной базы — универсальных значений нет, поэтому настройку лучше поручить администратору баз данных.
Сравнение вариантов
Подходит для файловых баз. Простой запуск, но требует монопольного доступа и работает медленно на больших объёмах
Подходит для клиент-серверных баз. Быстро, гибко, можно по расписанию, но требует квалификации администратора БД
Для автоматизации обслуживания файловых баз по расписанию. Нужен аккуратный контроль ошибок и логов
Риски и меры предосторожности
Реиндексация считается безопасной операцией, но она интенсивно нагружает дисковую подсистему и, в случае перестроения индексов на SQL Server, может удерживать блокировки. Запускать её в разгар рабочего дня на активной базе — плохая идея: пользователи столкнутся с тормозами и ошибками превышения времени ожидания блокировок.
Перед началом убедитесь, что на диске достаточно свободного места: при перестроении индексов СУБД может потребоваться дополнительное пространство, сопоставимое с размером самих индексов. Нехватка места в середине операции — один из сценариев, приводящих к сбоям.
Как проверить результат
Самый простой способ оценить эффект — замерить время выполнения типовых операций до и после процедуры: формирование ключевого отчёта, проведение документа, открытие большого журнала. Улучшение должно быть заметным, если причиной замедления действительно была фрагментация.
В клиент-серверном варианте администратор БД может проверить уровень фрагментации индексов штатными средствами СУБД (например, системными представлениями в SQL Server) и убедиться, что после обслуживания он снизился до приемлемого уровня.
Как проверить результат
Вернулось к прежним значениям или быстрее
Не изменилось — причина не в индексах
Снизилась до низкого уровня
Осталась высокой — процедура не выполнилась или оборвалась
Отсутствуют
Есть ошибки — проверьте целостность базы
Обычная скорость отклика
Жалобы на блокировки — процедура шла в рабочее время
Типичные ошибки при реиндексации
На практике одни и те же ошибки повторяются регулярно. Их легко избежать, если понимать механику процесса.
Отдельная крайность — выполнять реиндексацию «на всякий случай» без анализа. Если база небольшая и работает быстро, частая реиндексация не даст ничего, кроме лишней нагрузки на диски. Решение должно опираться на признаки деградации производительности или данные о фрагментации.
Как выбрать действие
Что важно запомнить
Реиндексация — это перестроение индексов для ускорения выборок, а не лечение данных. Файловые базы обслуживаются через конфигуратор, клиент-серверные — средствами СУБД. Всегда делайте резервную копию, запускайте процедуру вне рабочего времени и проверяйте результат по скорости типовых операций.
Частые вопросы о реиндексации в 1С
Можно ли запускать реиндексацию, пока пользователи работают?
В файловой базе — нет, процедура требует монопольного доступа. В клиент-серверной технически возможна реорганизация индексов «на лету», но она создаёт нагрузку, поэтому обслуживание планируют на нерабочие часы.
Как часто нужно делать реиндексацию?
Единого норматива нет. Для активно изменяемых баз обычно достаточно периодичности от раза в неделю до раза в месяц; для малоиспользуемых баз — по факту замедления. Ориентируйтесь на фрагментацию индексов и скорость работы.
Поможет ли реиндексация при ошибках «объект не найден» и битых ссылках?
Нет. Такие ошибки связаны с нарушением целостности данных, а не с индексами. Используйте проверку ссылочной целостности в «Тестировании и исправлении» и анализируйте, как возникли битые ссылки.
Чем реиндексация отличается от обновления статистики?
Реиндексация перестраивает физическую структуру индексов, а обновление статистики даёт оптимизатору СУБД свежие данные о распределении значений для выбора плана запроса. Это разные операции, в клиент-серверных базах их обычно выполняют вместе.
Опасно ли прервать реиндексацию файловой базы?
Да. Прерывание процесса (закрытие конфигуратора, отключение питания) может оставить файл базы в повреждённом состоянии. Именно поэтому перед запуском обязательна резервная копия.
Нужна ли реиндексация после обновления конфигурации?
Если обновление меняло структуру таблиц и индексов, платформа перестраивает их при реструктуризации автоматически. Отдельная реиндексация имеет смысл после массовых загрузок данных или заметного замедления работы.