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

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

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

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

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

Индекс в базе данных — это упорядоченная структура, построенная по одному или нескольким полям таблицы. Когда 1С ищет документ по номеру, отбирает проводки за период или рассчитывает итоги по регистру, сервер SQL использует индекс как оглавление книги: вместо перебора всех строк он сразу переходит к нужным записям. Без индексов любая выборка превращается в полное сканирование таблицы, что на больших объёмах занимает в разы больше времени.

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

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

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

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

Кроме того, реиндексация показана после определённых событий: массовой загрузки или удаления данных (например, свёртки базы), восстановления из резервной копии, миграции на другой сервер, обновления платформы или конфигурации с реструктуризацией таблиц. В файловом варианте 1С реиндексация через конфигуратор также помогает при ошибках вида «ошибка формата потока» и повреждениях индексных страниц файла 1Cv8.1CD.

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

Реиндексация через конфигуратор 1С

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

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

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

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

Реиндексация средствами СУБД

Для клиент-серверных баз более эффективный путь — обслуживание на уровне самой СУБД. В MS SQL Server индексы перестраиваются командами ALTER INDEX REBUILD (полное перестроение) или REORGANIZE (реорганизация при умеренной фрагментации). Как правило, при фрагментации выше примерно 30% рекомендуется REBUILD, в диапазоне примерно 10–30% достаточно REORGANIZE — эти пороги приведены в документации Microsoft и широко используются администраторами как ориентир.

На практике обслуживание автоматизируют: создают план обслуживания (Maintenance Plan) или скрипт, который ночью или в выходные перестраивает индексы и обновляет статистику по всем таблицам базы. Для PostgreSQL аналогичные задачи решают команды REINDEX и VACUUM ANALYZE. Такой регламент особенно важен для баз с интенсивной записью — торговых и производственных систем, где данные меняются ежедневно в больших объёмах.

Важный нюанс: полное перестроение индекса (REBUILD) в редакциях SQL Server без поддержки online-операций блокирует таблицу, поэтому выполнять его нужно вне рабочего времени. Также REBUILD требует свободного места в файлах базы и журнале транзакций — на больших таблицах журнал может вырасти существенно, что нужно учитывать при планировании.

ALTER INDEX ALL ON _Document123 REBUILD;  -- перестроение всех индексов таблицы в MS SQL Server

Чем реиндексация отличается от смежных процедур

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

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

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

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

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

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

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

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

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