Что такое индексирование в 1С и как оно ускоряет работу базы

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

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

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

Как устроены индексы в 1С

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

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

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

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

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

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

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

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

Главный критерий — реквизит регулярно используется в условиях поиска: в отборах динамических списков, в конструкциях «ГДЕ» запросов, в соединениях таблиц, при программном поиске методами «НайтиПоРеквизиту». Типичные кандидаты: ИНН и КПП контрагентов, артикулы и штрихкоды товаров, номера внешних документов, коды синхронизации с внешними системами.

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

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

Чем вредны лишние индексы

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

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

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

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

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

Для клиент-серверных баз полезно посмотреть план запроса на стороне СУБД. Если в плане вместо полного сканирования таблицы (Table Scan / Seq Scan) появляется поиск по индексу (Index Seek / Index Scan), индекс используется. Если план не изменился — возможно, СУБД считает полный просмотр выгоднее из-за низкой селективности или устаревшей статистики.

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

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

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

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

Норма

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

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

Список по-прежнему «думает» секундами

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

Норма

Используется Index Seek по созданному индексу

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

Остался полный просмотр таблицы

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

Норма

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

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

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

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

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

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

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

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

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

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

Чем индексирование отличается от полнотекстового поиска?

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

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

Как правило, нет. Если отбор выполняется пару раз в месяц и занимает несколько секунд, цена индекса в виде замедления записи и роста базы выше выгоды. Индексируйте поля с регулярными отборами в повседневной работе пользователей.

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

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

Опасно ли обновление конфигурации при добавлении индекса?

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

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

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