Администрирование · 10 мин
Индексирование 1С: для чего нужно и как выполнить
Что такое индексирование базы 1С, зачем нужна реиндексация, когда её запускать и как выполнить через конфигуратор безопасно. Признаки повреждения индексов и ошибки.
Индексы в 1С — это служебные структуры данных, которые ускоряют поиск записей в таблицах информационной базы. Когда пользователь ищет документ по номеру, открывает справочник контрагентов или строит отчёт по регистру, платформа обращается не ко всей таблице целиком, а к индексу — упорядоченному «каталогу» ключевых полей. Без индексов каждая операция превращалась бы в полный перебор миллионов строк, и работа базы замедлилась бы в десятки раз.
Индексирование (реиндексация) — это процедура полного пересоздания индексов таблиц базы данных. Она нужна в двух ситуациях: когда индексы повреждены и база работает с ошибками, и когда индексы «разбухли» и фрагментировались после массовых загрузок и удалений данных, из-за чего запросы начали выполняться медленнее. Процедура штатная и безопасная при соблюдении условий, но требует монопольного доступа к базе.
Что такое индексы и как они работают в 1С
Платформа 1С автоматически создаёт индексы для ключевых полей: номеров и дат документов, кодов и наименований справочников, измерений регистров. Разработчик может дополнительно пометить реквизит признаком «Индексировать», если по нему часто выполняется поиск или отбор — например, по артикулу номенклатуры или ИНН контрагента.
Индекс хранится отдельно от основных данных и обновляется при каждой записи. Когда вы проводите документ, платформа изменяет не только таблицу документов, но и все связанные индексы. При интенсивной работе — десятки тысяч записей в день — индексы постепенно фрагментируются: физический порядок страниц перестаёт совпадать с логическим, и чтение замедляется.
Зачем нужна реиндексация: основные сценарии
Первая и главная причина — повреждение индексов. Оно возникает при аварийном завершении работы: отключении электричества, разрыве соединения с сервером 1С или СУБД, принудительном завершении процесса, сбоях дисковой подсистемы. Повреждённый индекс ведёт на несуществующие или неверные записи, и база начинает вести себя непредсказуемо.
Вторая причина — деградация производительности. После свёртки базы, массовой загрузки данных через обработки, удаления больших объёмов документов индексы становятся неоптимальными. Характерный признак: отчёты и журналы документов, которые раньше открывались за секунды, теперь «думают» по несколько минут, хотя объём данных не вырос.
Третья ситуация — регламентное обслуживание файловых баз. Файловый вариант 1С (файл 1Cv8.1CD) не имеет средств автоматической дефрагментации индексов, поэтому для активно используемых файловых баз реиндексацию рекомендуется выполнять периодически — например, раз в месяц при интенсивной работе.
Появляются при открытии списков или документов
Поиск по индексу не находит существующие данные
Особенно после свёртки или массовой загрузки
Для клиент-серверных баз — в журнале SQL Server или PostgreSQL
Как выполнить реиндексацию файловой базы
Для файловой базы процедура выполняется через конфигуратор. Обязательное условие — монопольный доступ: все пользователи должны выйти из программы, фоновые задания и сеансы завершены. Проверить активные сеансы можно через меню «Администрирование — Активные пользователи» в режиме предприятия.
Порядок действий: откройте базу в конфигураторе, перейдите в меню «Администрирование — Тестирование и исправление». В открывшейся форме отметьте только пункт «Реиндексация таблиц информационной базы», остальные проверки для чистой реиндексации включать не обязательно. Выберите режим «Тестирование и исправление» и нажмите «Выполнить».
- 1Сделайте резервную копию: скопируйте файл 1Cv8.1CD или выгрузите базу в dt
- 2Завершите все сеансы пользователей и фоновые задания
- 3Откройте базу в конфигураторе
- 4Выберите «Администрирование — Тестирование и исправление»
- 5Отметьте пункт «Реиндексация таблиц информационной базы»
- 6Нажмите «Выполнить» и дождитесь завершения
- 7Проверьте работу базы: откройте журналы, справочники, типовой отчёт
Время выполнения зависит от размера базы и скорости диска. Небольшая база в несколько гигабайт обрабатывается за минуты, крупная файловая база может перестраивать индексы час и более. Прерывать процесс нельзя — это может привести к повреждению файла данных.
Особенности реиндексации клиент-серверных баз
В клиент-серверном варианте (MS SQL Server, PostgreSQL) индексы хранятся и управляются средствами СУБД. Запуск «Тестирования и исправления» из конфигуратора для таких баз возможен, но для планового обслуживания правильнее использовать штатные механизмы СУБД: перестроение или реорганизацию индексов через план обслуживания, обновление статистики.
Это принципиальное отличие: серверные СУБД умеют перестраивать индексы без полной блокировки базы (в ряде редакций — в online-режиме), делать это по расписанию и только для фрагментированных индексов. Поэтому для клиент-серверных баз реиндексация — обычно регламентная задача администратора СУБД, а не разовая аварийная процедура.
Файловая и клиент-серверная база
Реиндексация только через конфигуратор, монопольный доступ обязателен, нет автоматического обслуживания индексов
Индексы обслуживаются средствами СУБД по расписанию; «Тестирование и исправление» нужно в основном при подозрении на повреждение данных
Чем реиндексация отличается от других проверок
В окне «Тестирование и исправление» помимо реиндексации есть проверка логической целостности, проверка ссылочной целостности и пересчёт итогов. Их часто запускают «пачкой», хотя задачи у них разные. Реиндексация перестраивает только индексы и не исправляет данные.
Проверка логической целостности ищет повреждения в структуре самих данных, ссылочная целостность — «битые» ссылки на несуществующие объекты, пересчёт итогов восстанавливает итоговые значения регистров. Если подозрение только на медленную работу или «пропавшие» в списках записи — достаточно реиндексации, полное тестирование займёт в разы больше времени.
Типичные ошибки и ограничения
Самая частая ошибка — запуск процедуры без выгона пользователей. При не-монопольном доступе конфигуратор либо откажется выполнять операцию, либо, что хуже, процедура завершится некорректно при обрыве чужого сеанса. Вторая ошибка — отсутствие свежей копии: реиндексация редко, но может оборваться на повреждённом файле, и без копии восстановление станет сложной задачей.
Ограничение файлового варианта: реиндексация не решает проблему роста файла. Удалённые данные оставляют пустое место внутри 1Cv8.1CD, и для его сжатия нужна отдельная операция — выгрузка и загрузка базы через dt. Также реиндексация не заменяет обновление статистики в клиент-серверных базах: устаревшая статистика заставляет оптимизатор СУБД строить плохие планы запросов даже при исправных индексах.
Как проверить результат
После завершения процедуры убедитесь, что в окне сообщений конфигуратора нет ошибок — только информационные записи о выполнении. Затем откройте базу в режиме предприятия и проверьте те места, где наблюдались проблемы: журнал документов, в котором «пропадали» записи, отчёт, который тормозил, справочник, выдававший ошибку.
Дополнительная проверка — поиск по полям, по которым раньше возвращались пустые результаты. Если записи находятся, списки открываются быстро, а ошибки формата потока исчезли — реиндексация достигла цели. Если симптомы сохранились, следующий шаг — полное тестирование и исправление с проверкой логической и ссылочной целостности, а для файловой базы — проверка диска на ошибки.
Что важно запомнить
Реиндексация перестраивает индексы поиска и нужна при их повреждении или деградации скорости работы. Для файловой базы она выполняется через «Тестирование и исправление» в конфигураторе при монопольном доступе, для клиент-серверной — преимущественно средствами СУБД. Всегда начинайте с резервной копии.
Частые вопросы
Как часто нужно делать реиндексацию файловой базы?
Жёсткого регламента нет: ориентируйтесь на интенсивность работы. При ежедневном вводе большого числа документов разумно выполнять процедуру раз в месяц, при умеренной работе — раз в квартал или по факту замедления. Обязательна реиндексация после свёртки базы и массовых загрузок данных.
Можно ли прервать реиндексацию, если она идёт слишком долго?
Категорически не рекомендуется: принудительное завершение процесса конфигуратора во время перестроения индексов может повредить файл базы. Если процедура идёт неприемлемо долго, дождитесь её окончания, а в следующий раз планируйте запуск на нерабочее время — ночь или выходные.
Удаляет ли реиндексация помеченные объекты?
Нет. Реиндексация работает только со служебными структурами поиска и не трогает сами данные. Удаление помеченных объектов выполняется отдельной штатной операцией в режиме предприятия через «Администрирование — Удаление помеченных объектов».
Чем реиндексация отличается от утилиты chdbfl.exe?
Реиндексация — штатная процедура перестроения индексов исправной или слегка повреждённой базы. Утилита chdbfl.exe из каталога платформы предназначена для проверки физической целостности файла 1Cv8.1CD, когда база вообще не открывается. Сначала пробуют штатные средства, утилиту — при серьёзных повреждениях файла.
Почему после реиндексации база всё равно работает медленно?
Индексы — лишь одна из причин медленной работы. Проверьте объём свободной памяти и скорость диска, наличие неоптимальных запросов в доработках, устаревшую статистику в СУБД, размер журнала регистрации. Если база файловая и выросла свыше нескольких гигабайт при активной работе нескольких пользователей — возможно, ресурс файлового режима исчерпан и стоит рассмотреть переход на клиент-серверный вариант.