Индексация таблиц в 1С: что это такое и как ею управлять

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда нужны составные и дополнительные индексы

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

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

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

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

Типичные симптомы недостатка индексов: список документов с отбором открывается десятками секунд, отчёт «висит» на большом периоде, проведение по партиям замедляется по мере роста базы, а на стороне СУБД видны длительные запросы с операциями полного сканирования (Table Scan, Clustered Index Scan вместо Index Seek). При этом процессор сервера СУБД загружен, а дисковая очередь растёт.

Инструменты диагностики: технологический журнал 1С с событиями DBMSSQL/DBPOSTGRS показывает текст и длительность запросов; в MS SQL Server план выполнения запроса явно укажет на сканирование и подскажет недостающие индексы (missing index); консоль запросов с замером времени помогает сравнить поведение до и после изменений.

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

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

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

Норма

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

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

Table Scan или Clustered Index Scan по большой таблице

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

Норма

Запрос выполняется за доли секунды на рабочем объёме данных

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

Время растёт линейно с ростом таблицы

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

Норма

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

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

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

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

Главная ошибка — индексировать всё подряд. Каждый индекс занимает место на диске (иногда сопоставимо с размером самой таблицы), замедляет вставку и обновление записей и увеличивает время реструктуризации и обслуживания базы. На таблицах с интенсивной записью, например регистрах накопления в крупной торговой компании, лишние индексы способны ощутимо уронить производительность проведения документов.

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

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

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

Нужно ли индексировать таблицы в файловой базе 1С?

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

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

Первый вариант создаёт индекс только по значению реквизита. Второй добавляет в индекс поле упорядочивания объекта (для документов — дату), что ускоряет динамические списки с отбором по реквизиту и сортировкой по дате. Если реквизит используется в отборах журналов, обычно выбирают второй вариант.

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

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

Можно ли создавать индексы напрямую в СУБД, минуя конфигуратор?

Технически можно, и иногда так делают для нестандартных случаев (например, отфильтрованные индексы в MS SQL Server). Но такие индексы не видны платформе: при реструктуризации они могут быть удалены, а конфигурация не будет отражать реальную структуру базы. Предпочтительный путь — индексы средствами конфигуратора.

Как часто нужно перестраивать индексы на сервере?

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

Влияет ли индексация на обмен данными и выгрузку?

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