Что быстрее в 1С: регистр сведений или справочник

Вопрос «что быстрее — регистр сведений или справочник» возникает у разработчиков 1С почти на каждом проекте, где нужно хранить дополнительные свойства объектов, настройки или историю значений. Однозначного ответа «один всегда быстрее» нет: производительность зависит от типа операции — чтение по ключу, массовая выборка, запись, поиск по неиндексированному полю. Но закономерности есть, и они хорошо предсказуемы.

Ключевое отличие в архитектуре: справочник — это объектная сущность с уникальной ссылкой (GUID), иерархией, кодом, наименованием и предопределёнными элементами. Регистр сведений — это плоская таблица «измерения + ресурсы + период», где записи адресуются комбинацией измерений. Платформа работает с ними по-разному, и это напрямую влияет на скорость.

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

Как платформа хранит данные: почему это влияет на скорость

Справочник на уровне СУБД — это таблица с обязательными системными полями: ссылка (16-байтовый GUID), код, наименование, пометка удаления, предопределённость, владелец, родитель. Каждое обращение к элементу через объектную модель (НайтиПоКоду, ПолучитьОбъект) тянет за собой эту инфраструктуру. При создании элемента платформа генерирует GUID, проверяет уникальность кода (если включён контроль), обновляет служебные поля.

Регистр сведений — таблица, где первичный ключ (и кластерный индекс при правильном проектировании) строится по измерениям. Нет GUID, нет кода и наименования, нет иерархии. Запись набора — это фактически один пакет INSERT/DELETE в одну таблицу. Поэтому при массовых операциях регистр сведений почти всегда выигрывает: меньше данных на строку, меньше проверок, компактнее индексы.

Скорость чтения: где регистр сведений обгоняет

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

Справочник читается быстро только по ссылке (прямой доступ по GUID) или по коду — если включена уникальность кода и есть индекс. Поиск по наименованию или произвольному реквизиту без индекса превращается в перебор таблицы. При этом типовая ошибка — хранить «дополнительные свойства» номенклатуры в виде элементов справочника с реквизитом-владельцем и искать их запросом по реквизиту: на больших объёмах это медленнее, чем регистр сведений с измерением «Номенклатура».

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

Скорость записи и массовых операций

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

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

1. 1
   Создайте тестовую обработку с замером через ТекущаяУниверсальнаяДатаВМиллисекундах()
2. 2
   Выполните 1000 чтений по ключу из регистра и 1000 поисков по реквизиту справочника
3. 3
   Повторите замер для записи: 1000 элементов справочника против набора записей на 1000 строк
4. 4
   Сравните время и проверьте план запроса в консоли СУБД при расхождении с ожиданиями

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

Если значение используется как ссылка в документах и других объектах — справочник вне конкуренции. Реквизит типа «СправочникСсылка» хранит 16-байтовый GUID, и соединение по нему в запросах работает быстро. Хранить в документе строку или число и соединять её с регистром сведений — медленнее и ломает ссылочную целостность: удаление записи регистра не контролируется платформой.

Справочник также выигрывает при иерархических выборках (проверка «входит в группу» через В ИЕРАРХИИ), при необходимости предопределённых элементов, прав доступа на уровне объектов (RLS по ссылкам) и стандартных механизмов вроде истории изменений через версионирование.

Сравнение вариантов

Регистр сведений

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

Справочник

Ссылки, иерархия, целостность, предопределённые элементы. Ограничение: дороже запись, медленнее поиск по неиндексированным реквизитам.

Справочник + регистр сведений

Комбинация: объект хранится в справочнике, а часто меняющиеся свойства — в регистре. Оптимально для цен, статусов, настроек.

Роль индексов и режимов регистра

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

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

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

Типовой пример: хранение цен и штрихкодов

Классическая задача — цены номенклатуры. Реализация через справочник «Цены» с реквизитами «Товар» и «Цена» работает, но поиск цены товара — это запрос по неиндексированному реквизиту, а прайс на тысячи позиций — тысячи элементов справочника с полной объектной нагрузкой.

Реализация через периодический регистр сведений с измерениями «Номенклатура» и «ВидЦены» и ресурсом «Цена» даёт: мгновенное получение актуальной цены срезом последних, дешёвую загрузку прайсов набором записей, естественную историю изменения цены. Именно так это устроено в типовых конфигурациях — и причина именно в производительности.

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

Частые ошибки при выборе между объектами

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

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

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

Как принять решение: алгоритм выбора

Пройдите по трём вопросам. Первый: нужны ли ссылки на эти данные из документов, других справочников или планов обмена? Если да — справочник. Второй: нужна ли история значений или быстрый доступ по ключу «объект + параметр»? Если да — регистр сведений, возможно периодический. Третий: каков объём записей и частота записи? При тысячах операций записи в день регистр сведений даст ощутимый выигрыш.

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

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

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

Нужно хранить значение по ключу (объект, параметр) и часто его читатьИспользуйте регистр сведений с измерениями под этот ключ

На данные ссылаются документы или нужна иерархияИспользуйте справочник

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

Запросы к регистру тормозятПроверьте порядок измерений и план запроса, добавьте индексы вместо смены объекта

Проверка результата после оптимизации

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

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

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

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

Время чтения значения по ключу

Норма

Единицы миллисекунд, стабильно при росте данных

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

Растёт линейно с объёмом таблицы — запрос не использует индекс

Запись пакета из 1000 строк

Норма

Одна транзакция набора записей, время в секундах

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

Тысяча отдельных транзакций через цикл Записать()

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

Норма

Index Seek по измерениям или ссылке

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

Table Scan или Index Scan по всей таблице

Ссылочная целостность

Норма

Поиск ссылок не находит битых ссылок после изменений

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

Есть ссылки на удалённые или несуществующие объекты

Часто задаваемые вопросы

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

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

Что быстрее: НайтиПоНаименованию или запрос к регистру сведений?

Запрос к регистру сведений по измерениям быстрее, если условие попадает в индекс. НайтиПоНаименованию использует индекс по наименованию только при точном совпадении без учёта регистра; поиск по части строки всегда медленный независимо от типа объекта.

Влияет ли периодичность регистра на скорость чтения?

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

Стоит ли переносить данные из справочника в регистр ради ускорения?

Только если на элементы нет ссылок и данные адресуются ключом. Сначала выполните поиск ссылок на объект и замерьте реальные операции: если узкое место — отсутствие индекса, дешевле добавить индекс, чем менять архитектуру.

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

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