Индексы в 1С: что это и как с ними работать

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

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

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

Что такое индекс и как он работает

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

Когда выполняется запрос с условием ГДЕ Контрагент = &Контрагент, СУБД проверяет, есть ли подходящий индекс. Если есть — выполняется быстрый поиск по индексу (index seek). Если нет — таблица читается целиком (полное сканирование), и время выполнения растёт пропорционально количеству записей. На таблице в несколько миллионов строк разница составляет секунды против долей секунды.

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

Какие индексы 1С создаёт автоматически

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

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

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

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

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

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

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

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

Когда индекс нужен, а когда вреден

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

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

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

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

Запрос или отбор по полю выполняется медленно на большой таблицеДобавьте индекс по этому полю и проверьте план запроса

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

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

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

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

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

На стороне СУБД план запроса показывает, используется ли индекс: оператор Index Seek означает поиск по индексу, а Table Scan или Clustered Index Scan — полное чтение таблицы. Если после добавления индекса план не изменился, возможно, условие запроса написано так, что индекс применить нельзя — например, функция наложена на поле в условии.

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

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

Время выполнения запроса

Норма

Снизилось в разы после добавления индекса

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

Не изменилось или выросло

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

Норма

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

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

Остался Table Scan или Scan по кластерному индексу

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

Норма

Практически не изменилась

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

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

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

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

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

Полнотекстовый поиск и его индексы

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

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

FAQ

Нужно ли индексировать измерения регистров вручную?

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

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

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

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

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

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

Второй вариант добавляет в индекс ссылку на объект, что ускоряет запросы, где по этому реквизиту не только отбирают, но и получают связанные данные или сортируют результат. Если реквизит используется только для отбора, достаточно обычного «Индексировать».

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

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

Влияет ли итоговое хранение регистров на индексы?

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