Разработка и Конфигурация · 12 мин
Что значит индексировать в 1С и как это влияет на работу базы
Что значит индексировать в 1С: назначение индексов, как включить индексирование реквизита, влияние на скорость поиска и отборов, типичные ошибки и проверка результата.
Индексировать в 1С — значит указать платформе, что по определённому реквизиту объекта (справочника, документа, регистра) нужно построить вспомогательную структуру данных, которая ускоряет поиск, отбор и сортировку. Без индекса система при каждом запросе вынуждена последовательно просматривать все строки таблицы, а с индексом — находит нужные записи почти мгновенно, даже если в таблице миллионы строк.
На практике индексирование чаще всего встречается в двух ситуациях. Первая — разработчик в конфигураторе включает свойство «Индексировать» у реквизита, потому что по нему пользователи ищут товары, контрагентов или документы. Вторая — пользователь или администратор сталкивается с медленной работой базы, и анализ показывает, что частые отборы выполняются по полям без индексов.
Индексы — не бесплатный ресурс. Каждый индекс занимает место в базе и замедляет запись: при сохранении документа платформа обновляет не только саму таблицу, но и все её индексы. Поэтому индексировать нужно осознанно — только те поля, которые реально участвуют в поиске и отборах. Ниже разберём, как это работает, где настраивается, какие варианты индексирования существуют и как проверить эффект.
Что такое индекс и зачем он нужен в 1С
Индекс в базе данных работает как алфавитный указатель в конце книги: вместо того чтобы листать все страницы подряд, вы сразу открываете нужную. Технически индекс — это отсортированная структура, в которой значения поля связаны с физическим расположением записей в таблице. Когда пользователь вводит в строку поиска наименование контрагента, платформа по индексу быстро определяет, где лежат подходящие записи.
В 1С часть индексов создаётся автоматически. Платформа всегда индексирует ссылку объекта, код и номер документа, дату документа, измерения регистров, владельца справочника и родителя для иерархических справочников. Этого достаточно для типовых операций, но прикладные реквизиты — артикул, ИНН, штрихкод, номер договора — по умолчанию не индексируются, и решение остаётся за разработчиком конфигурации.
Отсутствие нужного индекса проявляется характерными симптомами: поиск по строке в большом справочнике занимает секунды или минуты, динамические списки с отбором «подтормаживают», отчёты с отбором по реквизиту строятся заметно дольше, чем аналогичные отчёты по системным полям. В клиент-серверном варианте это видно и в плане запроса СУБД — там появляется операция полного сканирования таблицы.
Где в конфигураторе включается индексирование
Настройка выполняется в конфигураторе, в палитре свойств реквизита. Откройте объект (справочник, документ, регистр сведений, план видов характеристик), выделите нужный реквизит и найдите свойство «Индексировать». Доступны три значения: «Не индексировать», «Индексировать» и «Индексировать с дополнительным упорядочиванием».
Первый вариант — значение по умолчанию: индекс не строится. Второй создаёт обычный индекс по полю. Третий добавляет в индекс дату или ссылку как второе поле упорядочивания — это полезно для реквизитов документов, по которым часто строятся выборки с сортировкой по дате, например «все документы по контрагенту за период в хронологическом порядке».
- 1Откройте конфигуратор и найдите объект (справочник, документ, регистр) в дереве конфигурации.
- 2Разверните ветку «Реквизиты» и выделите нужный реквизит.
- 3В палитре свойств найдите пункт «Индексировать» и установите «Индексировать» или «Индексировать с дополнительным упорядочиванием».
- 4Сохраните конфигурацию и выполните обновление конфигурации базы данных (F7).
- 5Дождитесь завершения реструктуризации — на больших таблицах она может занять заметное время.
После изменения свойства платформа при обновлении конфигурации базы данных выполняет реструктуризацию — физически создаёт индекс в таблице. На больших таблицах (миллионы записей) это может занять от нескольких минут до часов, и в этот момент таблица может быть заблокирована для пользователей. Поэтому такие изменения в рабочей базе планируйте на нерабочее время.
Какие поля стоит индексировать, а какие — нет
Кандидаты на индексирование — поля, по которым регулярно выполняется поиск или отбор: ИНН и КПП контрагента, артикул и штрихкод номенклатуры, номер и дата входящего документа, номер телефона клиента, коды интеграции с внешними системами. Признак простой: если в интерфейсе есть поле поиска или в запросах есть условие «ГДЕ Реквизит = &Параметр» — поле стоит рассмотреть на индексирование.
Не стоит индексировать реквизиты с малым числом различных значений — например, булевы флаги («Проведён», «Архивный») или поля с двумя-тремя вариантами. По такому индексу СУБД всё равно не сможет сильно сузить выборку, а накладные расходы на его поддержку останутся. Также не имеет смысла индексировать длинные текстовые поля неограниченной длины и реквизиты, которые используются только для вывода на экран, но никогда — в отборах.
Варианты значения свойства «Индексировать»
Подходит для редко используемых в отборах реквизитов: комментариев, примечаний, служебных флагов. Экономит место и ускоряет запись.
Стандартный выбор для полей поиска: ИНН, артикул, штрихкод, номер договора. Ускоряет равные отборы и соединения.
Для реквизитов документов, по которым строятся списки с сортировкой по дате: отбор по контрагенту с хронологией документов.
Отдельный случай — регистры сведений. Для независимых регистров измерения индексируются автоматически, а вот ресурсы — нет. Если вы храните в ресурсе, например, штрихкод или фото-идентификатор и ищете по нему, индексирование ресурса даст заметный эффект. В подчинённых регистратору регистрах сведений поиск обычно идёт по регистратору, и он уже проиндексирован системой.
Как индексы влияют на скорость записи и размер базы
Каждая операция записи — проведение документа, создание элемента справочника, обмен данными — обновляет все индексы затронутых таблиц. Если у таблицы десяток индексов, вставка одной строки превращается в одиннадцать операций записи. На массовых загрузках (полная выгрузка товаров с сайта, первоначальное заполнение базы) это заметно увеличивает время.
Индексы также занимают дисковое пространство. Ориентировочно каждый индекс по одному полю добавляет к размеру таблицы заметную долю — в зависимости от типа данных и количества строк это могут быть проценты или десятки процентов от размера самой таблицы. В файловом варианте это влияет на размер файла 1Cv8.1CD, в клиент-серверном — на объём базы в СУБД.
Практический вывод: индексирование — это компромисс между скоростью чтения и скоростью записи. Для справочников, которые читаются часто, а пишутся редко (номенклатура, контрагенты), индексы по полям поиска почти всегда оправданы. Для регистров с интенсивной записью (регистры продаж в крупной рознице) каждый дополнительный индекс нужно обосновывать конкретным отчётом или отбором.
Индексирование в запросах и динамических списках
Даже правильно расставленные индексы не помогут, если запрос написан так, что СУБД не может их использовать. Классические случаи: функция над полем в условии («ГДЕ ПОДСТРОКА(Наименование, 1, 5) = &Строка»), неявное преобразование типов, условие «ИЛИ» по полям разных таблиц. В таких конструкциях индекс игнорируется, и выполняется полное сканирование.
В динамических списках платформа сама строит запрос с учётом установленного пользователем отбора. Если пользователь включает отбор по неиндексированному полю большой таблицы, список будет открываться медленно у всех, кто работает с этой формой. Решение — либо проиндексировать поле, либо ограничить доступные для отбора поля в настройках динамического списка.
Для клиент-серверного варианта полезно уметь смотреть план запроса на стороне СУБД. Если в плане по условию отбора выполняется полное сканирование таблицы (Full Table Scan, Seq Scan, Clustered Index Scan без сужения), значит подходящего индекса нет или запрос его не использует. Это прямой сигнал пересмотреть либо индексы, либо текст запроса.
Проверка результата и типичные ошибки
После включения индексирования убедитесь, что эффект действительно достигнут. Самый простой способ — замерить время выполнения характерной операции до и после: открытие списка с отбором, поиск по строке, построение отчёта. В клиент-серверном варианте дополнительно проверьте план запроса — сканирование должно смениться поиском по индексу (Index Seek).
Как проверить результат
Поиск и отбор выполняются заметно быстрее, чем до изменения
Время не изменилось — индекс не создан или запрос его не использует
В плане фигурирует поиск по индексу (Index Seek / Index Scan)
Осталось полное сканирование таблицы
Проведение документов и обмены работают в прежнем темпе
Запись заметно замедлилась — индексов слишком много
Обновление конфигурации БД завершилось без ошибок
Реструктуризация прервана — индекс может быть не создан
Типичные ошибки связаны либо с избытком, либо с неправильным применением индексов. Индексирование всех реквизитов подряд приводит к замедлению записи без выигрыша в чтении. Включение индекса по полю, которое в запросе оборачивается функцией, не даёт эффекта — нужно переписывать запрос. Ещё одна ошибка — забыть, что в файловом варианте лишний индекс раздувает файл базы и удлиняет тестирование и исправление.
FAQ: частые вопросы об индексировании в 1С
Нужно ли индексировать наименование справочника?
Обычно нет: поиск по наименованию с вводом подстроки («содержит») индекс всё равно не использует — эффективнее работает полнотекстовый поиск. Индекс по наименованию имеет смысл, только если выполняется поиск точного совпадения или сортировка по наименованию в больших выборках.
Чем индексирование отличается от полнотекстового поиска?
Обычный индекс ускоряет точные сравнения и отборы «равно/больше/меньше». Полнотекстовый поиск строит отдельный индекс по словам и находит записи по фрагментам текста с учётом морфологии. Это разные механизмы, настраиваются независимо и дополняют друг друга.
Почему после включения индексирования база стала больше?
Индекс — физическая структура, которая хранит копию значений поля в отсортированном виде. Чем больше строк в таблице и длиннее значения поля, тем больше места занимает индекс. Это нормальная плата за ускорение поиска.
Можно ли включить индексирование без конфигуратора?
Нет, свойство «Индексировать» меняется только в конфигураторе с последующим обновлением конфигурации базы данных. В клиент-серверном варианте администратор СУБД теоретически может создать индекс средствами СУБД, но такой индекс не будет известен платформе и может конфликтовать с реструктуризацией — это не рекомендуемый путь.
Как понять, каких индексов не хватает в базе?
Начните с жалоб пользователей: какие списки и отчёты работают медленно. Затем проанализируйте условия отбора в этих объектах и сопоставьте их с проиндексированными полями. В клиент-серверном варианте используйте план запроса и встроенные средства СУБД по поиску недостающих индексов.
Замедлит ли индексирование проведение документов?
Каждый дополнительный индекс немного замедляет запись, но для одного-двух индексов по полям поиска эффект обычно незаметен. Проблемы возникают при массовом индексировании таблиц с интенсивной записью — там каждый индекс нужно обосновывать замерами.
Что важно запомнить
Индексировать в 1С — значит включить построение индекса по реквизиту для ускорения поиска и отборов. Включается в конфигураторе через свойство «Индексировать». Индексируйте только поля реальных отборов, помните о цене: замедление записи и рост базы. Эффект проверяйте замерами и планом запроса, а изменения в рабочей базе выполняйте в нерабочее время.