← На главную

При проектировании структуры регистров накопления в платформе «1С:Предприятие» разработчики часто задаются вопросом: создается ли физический индекс по первому измерению автоматически или для него необходимо явно указывать свойство Индексировать? Разберем подробно, как платформа взаимодействует с реляционными СУБД (например, Microsoft SQL Server), какие индексы генерируются для физических таблиц регистров оборотов и остатков и как это влияет на производительность системы.

Особенности индексации в оборотных регистрах накопления

Рассмотрим поведение системы на примере регистра накопления с типом вида регистра Обороты. Проанализируем физические таблицы СУБД, которые платформа создает для обеспечения работы данного объекта метаданных.

Для регистра оборотов платформа формирует основную таблицу движений и физическую таблицу оборотов. Экспериментальная проверка и анализ таблиц на стороне СУБД показывают следующее правило:

1. Без флага индексирования: Если для первого (или любого другого) измерения свойство Индексировать установлено в значение Не индексировать, отдельный физический индекс по данному полю в таблице СУБД не создается.
2. С установленным флагом: Физический индекс по измерению (вида ИЗМЕРЕНИЕ + ПЕРИОД + РЕГИСТРАТОР + НОМЕР СТРОКИ) генерируется в таблицах СУБД только при явном включении свойства Индексировать в конфигураторе.

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

Особенности индексации в регистрах накопления остатков

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

В регистрах остатков создаются две ключевые структуры:

1. Таблица итогов (физическая таблица остатков): Платформа всегда автоматически создает кластерный составной индекс вида ПЕРИОД + ИЗМЕРЕНИЕ 1 + ИЗМЕРЕНИЕ 2 + ... + ИЗМЕРЕНИЕ N. Данный индекс включает в себя все измерения в порядке их следования в дереве метаданных конфигуратора.
2. Дополнительные индексы по измерениям: Если для конкретного измерения (например, ИЗМЕРЕНИЕ К) установлено свойство Индексировать, платформа дополнительно формирует отдельный индекс вида ПЕРИОД + ИЗМЕРЕНИЕ К.

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

Принцип работы составных индексов и правило левого префикса

Проанализируем механизм работы составных индексов реляционных СУБД. Составной индекс работает по принципу слева направо (правило левого префикса):

Если условие в запросе накладывает отбор на первое измерение (или группу первых измерений в порядке их задания в метаданных), СУБД выполняет быстрый поиск по существующему составному индексу (операция Index Seek). Отдельный одиночный индекс для первого измерения в этом случае не требуется, а его принудительная установка приводит к дублированию индексных структур на диске.

При проектировании структуры метаданных рекомендуем соблюдать следующие правила относительно порядка измерений:

1. На самые первые позиции в дереве метаданных регистра помещаем наиболее селективные измерения (с большим количеством уникальных значений), по которым чаще всего выполняются отборы.
2. Для первого измерения регистра остатков флаг Индексировать обычно не требуется, так как оно покрывается главным составным индексом итогов.
3. Для последующих измерений (начиная со второго и далее), если по ним часто выполняются самостоятельные отборы в отчетах или запросах без указания первых измерений, необходимо устанавливать свойство Индексировать.

Влияние избыточного индексирования на скорость записи и блокировки

Выясним, к каким последствиям приводит необоснованное включение признака Индексировать на измерениях и реквизитах регистра.

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

1. Увеличение времени выполнения транзакции записи.
2. Рост времени блокировок таблиц и эскалацию блокировок СУБД.
3. Повышение риска возникновения взаимных блокировок (deadlocks) при параллельной работе пользователей.

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