Что значит переиндексировать таблицы базы данных в 1С

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

Когда говорят «переиндексировать таблицы в 1С», обычно имеют в виду либо штатную операцию в конфигураторе (Тестирование и исправление → Реиндексация таблиц), либо перестроение индексов средствами СУБД для клиент-серверных баз на Microsoft SQL Server или PostgreSQL. Оба подхода решают одну задачу — восстановить эффективность индексов, но выполняются разными инструментами и в разных условиях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Переиндексация в клиент-серверных базах

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

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

ALTER INDEX ALL ON _Document123 REBUILD WITH (ONLINE = OFF);

В PostgreSQL используют команду REINDEX — для отдельной таблицы, схемы или всей базы. Важно учитывать, что классический REINDEX блокирует таблицу на запись; в поддерживающих версиях есть вариант REINDEX CONCURRENTLY, работающий без долгой блокировки, но медленнее. Конкретный синтаксис и доступные опции зависят от версии СУБД — сверяйтесь с её документацией.

Дополнительно к перестроению индексов на клиент-серверных базах обновляют статистику: оптимизатор запросов СУБД строит планы выполнения на основе статистических данных о распределении значений, и устаревшая статистика даёт неэффективные планы даже при исправных индексах. В SQL Server это команда UPDATE STATISTICS, в PostgreSQL — ANALYZE.

Когда нужна переиндексация, а когда — нет

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

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

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

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

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

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

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

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

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

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

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

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