При разработке собственных планов счетов и регистров бухгалтерии программисты 1С иногда сталкиваются с парадоксальной ситуацией: объем данных в базе относительно невелик, а размер индексов в SQL-базе исчисляется гигабайтами, значительно превышая объем аналогичных таблиц в типовых конфигурациях. Разберем, почему так происходит, и как оптимизировать структуру метаданных для экономии дискового пространства и повышения производительности.
Первое, на что необходимо обратить внимание — это свойство Максимальное количество субконто в ПланеСчетов. В рассматриваемом случае увеличение этого параметра с типовых 3 до 5 приводит к резкому росту объема индексов. Проанализируем причину: платформа 1С автоматически генерирует системные составные индексы для обеспечения работы механизма итогов и быстрого получения остатков.
Количество этих индексов растет не линейно, а в геометрической прогрессии. Для каждой комбинации (Период, Счет, Субконто1...СубконтоN) создаются наборы уникальных и неуникальных индексов. Даже если на конкретном счете используется всего 3 субконто, но в целом в плане счетов разрешено 5, структура таблиц итогов на уровне СУБД будет рассчитана на хранение всех пяти измерений аналитики во всех возможных сочетаниях индексов.
Рекомендация: Если бизнес-логика позволяет, следует ограничить количество субконто до трех. Если же требуется большее количество аналитик, проанализируем возможность выноса части данных в Дополнительные реквизиты регистра бухгалтерии. Это исключит их из тяжелых индексов таблиц итогов, сохранив возможность формирования отчетов по движениям.
Одной из наиболее частых причин «раздувания» индексов является использование примитивных типов (Булево, Число, Строка) в ПланеВидовХарактеристик (ПВХ), который выступает типом для субконто. Рассмотрим подробнее, как это влияет на SQL-таблицы:
binary или nvarchar) может резервировать максимальную ширину для хранения самого длинного из возможных значений.Булево может значительно увеличить размер каждой индексной записи из-за особенностей выравнивания данных и хранения метаданных типа.Выясним причину на конкретном примере: если в ПВХ ВидыСубконто включен тип Булево, платформа вынуждена хранить информацию о типе значения для каждой записи. Вместо эффективного хранения ссылок на справочники, индексы начинают содержать избыточную информацию.
Решение: Замените примитивные типы на ссылочные. Вместо Булево создайте перечисление ДаНет или аналогичный справочник. Это позволит 1С оперировать фиксированным размером ссылки, что значительно сузит индексы.
Проанализируем ситуацию с точки зрения настроек самого регистра. Существенное влияние на размер оказывает режим Разделение итогов (Split totals). При его включении в таблицу итогов добавляется дополнительное поле — разделитель записей. В сочетании с большим количеством субконто это поле кратно увеличивает количество записей в таблицах итогов, так как остатки теперь хранятся в разрезе разделителей для предотвращения блокировок при высокоинтенсивной записи.
Также проверьте Признаки учета и Признаки учета субконто (например, количественный или валютный учет). Если у всех пяти субконто включены признаки учета, платформа генерирует отдельные наборы индексов для каждой комбинации этих признаков для корректного расчета итогов. Если количественный учет нужен только для одного субконто (например, Номенклатура), убедитесь, что он не включен для остальных «тяжелых» аналитик.
Если ТИИ (Тестирование и исправление) с реиндексацией не помогает, разберем шаги по технической очистке базы:
_AccRg (движения) и _AccRgTotals (итоги). Если вы видите десятки индексов, это подтверждает избыточность структуры метаданных.REBUILD индексов средствами SQL Server с оптимальным коэффициентом FILLFACTOR. Это поможет устранить фрагментацию, которую штатные средства 1С иногда не могут обработать эффективно.Важное правило архитектуры: Помните, что регистр бухгалтерии — это максимально жестко структурированный объект. Любое добавление аналитики (субконто) должно быть обосновано требованием получать по ней остатки. Если вам нужно просто видеть информацию в проводке (например, «Комментарий» или «Документ-основание» без учета остатков), всегда используйте Дополнительные реквизиты регистра, а не субконто. Это сохранит размер вашей базы в разумных пределах.