Индексы в 1С: для чего нужны и как их правильно использовать

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

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

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

Как индексы устроены и что они дают базе

Физически индекс — это отсортированная структура (в MS SQL и PostgreSQL обычно B-дерево), где хранятся значения индексированных полей и указатели на строки таблицы. Поиск по отсортированной структуре работает по принципу двоичного поиска: вместо миллиона сравнений достаточно нескольких десятков шагов.

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

Какие индексы платформа создаёт автоматически

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

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

Когда нужно добавлять индекс вручную

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

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

1. 1
   Откройте конфигуратор и найдите объект (документ, справочник, регистр)
2. 2
   В свойствах нужного реквизита установите «Индексировать» в «Индексировать» или «Индексировать с доп. упорядочиванием»
3. 3
   Обновите конфигурацию базы данных — платформа создаст индекс в СУБД
4. 4
   Проверьте время выполнения проблемного запроса до и после изменения

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

Как понять, что не хватает индекса

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

Для диагностики в клиент-серверном варианте используйте план запроса в СУБД (в MS SQL — фактический план выполнения в Management Studio). Признак проблемы — операции Clustered Index Scan или Table Scan на больших таблицах там, где ожидался поиск (Seek). Дополнительно полезен технологический журнал 1С с отбором по событиям DBMSSQL/DBPOSTGRS длительностью выше порога.

Когда индексы вредят

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

Индекс бесполезен по полю с низкой селективностью: например, по булеву флагу, где 95 % записей имеют одно значение. Оптимизатор СУБД такой индекс проигнорирует, а поддерживать его придётся. Также бессмысленно индексировать поля, по которым никто не отбирает и не соединяет таблицы.

Индексирование и запросы: что учитывать в коде

Индекс работает, только если запрос написан так, чтобы оптимизатор мог его применить. Условие вида ГДЕ Подразделение = &Подразделение использует индекс по полю «Подразделение». А условие с функцией над полем — например, ГДЕ ГОД(Дата) = 2026 — заставляет СУБД вычислять значение для каждой строки, и индекс по дате не применяется. Правильная замена — диапазон: ГДЕ Дата МЕЖДУ &Начало И &Конец.

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

Маршрут решения

Как выбрать действие

Отбор или соединение идут по реквизиту, индекса нет, таблица большаяВключите индексирование реквизита и проверьте план запроса

Индекс есть, но запрос всё равно медленныйПроверьте запрос на функции над полем, неравенства и OR — перепишите условие

Медленная запись при нормальной скорости чтенияПроанализируйте избыточные индексы и удалите неиспользуемые

Проблема в динамическом спискеПроверьте поля отбора и сортировки списка, добавьте индекс по комбинации этих полей

Проверка результата после изменения индексов

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

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

Контрольные точки

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

Время целевого запроса до и после добавления индекса

Норма

Устойчивое сокращение времени на тех же данных

Тревожный признак

Изменений нет — индекс не используется, смотрите план запроса

План выполнения в СУБД

Норма

Index Seek по нужному индексу

Тревожный признак

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

Скорость записи и проведения

Норма

Время записи не изменилось существенно

Тревожный признак

Проведение замедлилось — индексов слишком много

Размер базы

Норма

Прирост соответствует размеру новой структуры

Тревожный признак

Резкий рост без выигрыша в скорости

Частые вопросы об индексах в 1С

Нужно ли индексировать реквизиты в файловой базе?

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

Чем «Индексировать» отличается от «Индексировать с доп. упорядочиванием»?

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

Можно ли создать индекс по нескольким реквизитам документа?

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

Почему после добавления индекса запрос не ускорился?

Чаще всего оптимизатор не использует индекс: в условии есть функция над полем, неравенство, ИЛИ между разными полями или низкая селективность. Откройте план запроса в СУБД и проверьте, какой способ доступа к данным выбран фактически.

Нужно ли перестраивать (обслуживать) индексы?

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

Влияют ли индексы на регламентные задания и обмены?

Косвенно — да. Обмены и фоновые задания часто выбирают данные по служебным полям (признакам выгрузки, статусам). Если такие отборы не индексированы, задания выполняются дольше и создают нагрузку на сервер в фоне.