Что значит индексировать реквизит в 1С и когда это нужно

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

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

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

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

Когда вы устанавливаете свойство «Индексировать» у реквизита справочника или документа и обновляете конфигурацию базы данных, платформа 1С формирует команду на создание индекса в СУБД. В файловом варианте индекс создаётся внутри файла базы, в клиент-серверном — средствами Microsoft SQL Server, PostgreSQL или Oracle. Сам индекс представляет собой упорядоченную структуру (обычно B-дерево), где значения реквизита связаны со ссылками на строки таблицы.

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

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

Когда реквизит нужно индексировать

Главный критерий — реквизит участвует в поиске, отборах или соединениях, и таблица достаточно велика, чтобы полное сканирование ощущалось. Типичные кандидаты на индексацию:

• реквизиты, по которым пользователи ищут элементы в формах списка (артикул, штрихкод, ИНН контрагента, номер документа внешней системы);
• поля, по которым строятся отборы в отчётах и динамических списках (склад, организация, контрагент);
• реквизиты, используемые в соединениях таблиц в запросах (например, товар в табличной части документа, по которому идёт связь с регистром);
• поля, по которым выполняется поиск дублей при обмене данными или загрузке из файлов.

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

Как включить индексацию реквизита: пошагово

Действия выполняются в конфигураторе и требуют монопольного доступа к базе при обновлении. Порядок такой:

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

После обновления проверьте результат на реальных операциях: откройте список с отбором по этому реквизиту, выполните типовой запрос. В клиент-серверном варианте дополнительно полезно посмотреть план запроса средствами СУБД — индекс должен использоваться (index seek вместо table scan).

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

Чем индексирование отличается от похожих свойств

У реквизитов в 1С есть несколько свойств, которые часто путают с индексацией. Различия принципиальны:

Обычный индекс не помогает при поиске по подстроке вида «содержит текст» — для этого существует полнотекстовый поиск. И наоборот, полнотекстовый индекс не ускоряет точное сравнение и соединения. Это разные механизмы, и выбирать их нужно под конкретную задачу.

Цена индекса: почему нельзя индексировать всё подряд

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

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

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

Типичные ошибки и ограничения

Первая ошибка — ожидание, что индекс решит проблему медленного запроса автоматически. Если в условии запроса к полю применена функция (например, ПОДСТРОКА или приведение типа), СУБД не сможет использовать индекс по этому полю. Запрос нужно переписывать так, чтобы условие накладывалось на «чистое» поле.

Вторая ошибка — индексация реквизитов с низкой избирательностью. Если реквизит булевского типа или принимает два-три значения (например, «Проведён/Не проведён»), индекс по нему почти бесполезен: СУБД всё равно придётся читать половину таблицы. Индекс эффективен, когда по значению отбирается небольшая доля записей.

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

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

Как проверить, что индекс работает

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

В клиент-серверном варианте используйте технологический журнал и планы запросов СУБД. В SQL Server план выполнения покажет, используется ли Index Seek по созданному индексу или выполняется Scan. В PostgreSQL аналогичную информацию даёт команда EXPLAIN ANALYZE. Если индекс создан, но не используется — ищите причину в тексте запроса или в статистике СУБД.

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

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

Скорость отбора в списке

Норма

Отбор по реквизиту выполняется быстро, без зависаний

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

Список по-прежнему «подвисает» — индекс не используется

План запроса в СУБД

Норма

В плане есть Index Seek / Index Scan по новому индексу

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

Остался Table Scan — пересмотрите текст запроса

Скорость записи

Норма

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

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

Запись стала ощутимо медленнее — индексов слишком много

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

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

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

Ускорит ли индекс поиск по части строки, например по фрагменту наименования?

Нет. Обычный индекс работает при сравнении «равно» и поиске по началу строки. Для поиска по подстроке в произвольном месте текста используйте полнотекстовый поиск — это отдельный механизм со своим индексом.

Можно ли включить индексацию без остановки работы пользователей?

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

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

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

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

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

Сколько индексов допустимо на одну таблицу?

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