Что такое индекс в 1С и зачем он нужен

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

Индексы работают на уровне базы данных: в файловом варианте их поддерживает собственный движок платформы, в клиент-серверном — СУБД (Microsoft SQL Server, PostgreSQL и другие). Разработчик не управляет индексами напрямую — он только указывает в конфигураторе, какие поля объекта должны индексироваться, а платформа сама создаёт и поддерживает соответствующие структуры.

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

Как устроен индекс и почему он ускоряет поиск

Представьте справочник «Номенклатура» с миллионом позиций. Если пользователь ищет товар по артикулу, а индекса по этому полю нет, платформа вынуждена читать таблицу от первой до последней строки и сравнивать каждое значение. Такая операция называется полным сканированием таблицы и является главной причиной «тормозов» при поиске.

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

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

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

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

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

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

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

Ручное индексирование требуется для дополнительных реквизитов, которые разработчик добавил в объект: артикул, ИНН контрагента, штрихкод, номер заказа покупателя и подобные поля. Признак необходимости индекса — реквизит регулярно используется в условиях поиска, отборах динамических списков или соединениях таблиц в запросах.

Типичные сценарии, где индекс нужен:

1. Поиск элемента справочника методом НайтиПоРеквизиту() при обмене данными или загрузке из файлов.
2. Отбор в динамическом списке по реквизиту, который пользователи указывают в настройках.
3. Соединение таблиц в запросе по нестандартному полю.
4. Проверка уникальности введённого значения перед записью объекта.

Обратная ситуация — реквизит заполняется, но по нему никто не ищет. Например, многострочное поле «Комментарий» или служебное поле, которое выводится только в печатной форме. Индексировать такие поля бессмысленно: чтение не ускорится, а запись станет медленнее.

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

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

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

Реквизит только хранится и выводится на экран или в печатьИндексирование не включайте — это лишняя нагрузка при записи

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

Таблица маленькая (сотни записей)Индекс почти ничего не даст, но и не навредит — решайте по удобству

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

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

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

Свойство «Индексировать» имеет три значения. «Не индексировать» — индекс не создаётся. «Индексировать» — создаётся индекс по значению реквизита и ссылке. «Индексировать с дополнительным упорядочиванием» — в индекс дополнительно включается другое поле (например, дата), что ускоряет запросы вида «найти документы с таким реквизитом, упорядоченные по дате».

Для реквизитов табличных частей индексирование настраивается отдельно в свойствах самой табличной части и применяется редко — в основном когда по значениям строк строятся запросы с соединениями.

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

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

Чтобы запрос использовал индекс, соблюдайте простые правила. Условие должно накладываться на само поле, а не на выражение с ним: конструкция ГДЕ Номенклатура = &Номенклатура использует индекс, а ГДЕ ПОДСТРОКА(Наименование, 1, 5) = &Префикс — нет. Виртуальные таблицы регистров требуют задания параметров (период, условия) именно в параметрах виртуальной таблицы, а не в секции ГДЕ.

Проверить реальный план запроса в клиент-серверном варианте можно средствами СУБД: в Microsoft SQL Server — через план выполнения запроса в Management Studio, в PostgreSQL — через команду EXPLAIN. В файловом варианте ориентируйтесь на замеры времени выполнения до и после включения индекса.

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

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

Время поиска по реквизиту

Норма

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

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

Скорость не изменилась — индекс не используется или таблица мала

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

Норма

В плане видна операция Index Seek (поиск по индексу)

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

Операция Table Scan или Clustered Index Scan — идёт полное сканирование

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

Норма

Запись замедлилась незначительно

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

Запись заметно просела — вероятно, индексов слишком много

Типичные ошибки при работе с индексами

Большинство проблем с индексами связано не с их отсутствием, а с избыточным или неправильным применением. Разберём распространённые ошибки.

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

Индексы и производительность: где границы самостоятельной настройки

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

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

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

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

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

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

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

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

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

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

Нужно ли индексировать реквизиты типа «Строка» неограниченной длины?

Нет, и платформа этого не позволит: реквизиты неограниченной длины и типа «ХранилищеЗначения» индексировать нельзя. Если по строковому полю нужен поиск, задайте ему разумную фиксированную длину и только после этого включайте индексирование.

Что делать, если индексы повреждены и база работает с ошибками?

В файловом варианте запустите утилиту chdbfl.exe из каталога платформы с проверкой физической целостности, затем выполните тестирование и исправление в конфигураторе с включённой реиндексацией таблиц. Перед любыми такими операциями обязательно сделайте копию файла базы.

Отличается ли работа индексов в файловом и клиент-серверном варианте?

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