Разработка и Конфигурация · 10 мин
Индексировать с дополнительным упорядочиванием в 1С 8.3: что это и как использовать
Что означает свойство «Индексировать с дополнительным упорядочиванием» в 1С 8.3, как оно влияет на индексы и запросы, когда включать и как проверить результат.
В конфигураторе 1С 8.3 у реквизитов объектов (справочников, документов, регистров и других) есть свойство «Индексировать» с тремя вариантами: «Не индексировать», «Индексировать» и «Индексировать с доп. упорядочиванием». Третий вариант часто вызывает вопросы: чем он отличается от обычного индексирования и в каких случаях его нужно выбирать.
Коротко: обычное индексирование создаёт в базе данных индекс по значению реквизита. Вариант «с дополнительным упорядочиванием» создаёт составной индекс, в котором к значению реквизита добавляется ключ записи (для документа — дата и ссылка, для справочника — ссылка). Это ускоряет не только поиск по значению, но и упорядочивание результата запроса.
Чем три варианта свойства «Индексировать» отличаются друг от друга
При выборе «Не индексировать» по реквизиту индекс не создаётся. Поиск и отбор по такому полю в запросах и динамических списках будут выполняться полным сканированием таблицы — на больших объёмах данных это заметно медленно.
Вариант «Индексировать» создаёт индекс только по значению реквизита. Он ускоряет условия вида ГДЕ Реквизит = &Значение, но если запрос дополнительно сортирует результат (например, по дате документа), СУБД может не использовать этот индекс оптимально и выполнит отдельную сортировку выборки.
Вариант «Индексировать с доп. упорядочиванием» создаёт составной индекс: значение реквизита плюс ключ записи. Для документов это дата и ссылка, для справочников — ссылка. Такой индекс покрывает одновременно и поиск по значению, и упорядочивание выборки по ключу записи.
Сравнение вариантов
Подходит для служебных и редко используемых реквизитов. Поиск по полю будет медленным на больших таблицах.
Подходит, когда по реквизиту ищут равенство, но не сортируют результат. Минимальный размер индекса.
Подходит, когда по реквизиту ищут и упорядочивают результат (динамические списки, запросы с УПОРЯДОЧИТЬ ПО). Индекс больше, запись чуть медленнее.
Как устроен индекс с дополнительным упорядочиванием
На уровне СУБД (MS SQL Server, PostgreSQL и др.) обычный индекс по реквизиту содержит только его значение и указатель на строку. Платформа при включённом дополнительном упорядочивании формирует индекс, в котором после значения реквизита идут поля ключа записи.
Для документа такой индекс выглядит условно как (Реквизит, Дата, Ссылка). Это значит, что запрос «найти все документы с контрагентом X, упорядоченные по дате» выполняется по одному индексу без отдельной сортировки. Без дополнительного упорядочивания СУБД сначала нашла бы строки по контрагенту, а потом сортировала бы их по дате отдельной операцией.
Важно понимать: дополнительное упорядочивание работает в рамках одного значения реквизита. То есть записи сначала группируются по значению реквизита, а внутри группы упорядочены по ключу. Для запросов без отбора по реквизиту такой индекс обычно не даёт преимуществ перед обычным.
Когда стоит включать дополнительное упорядочивание
Основной сценарий — реквизит, по которому строится динамический список с отбором и сортировкой. Например, в журнале документов пользователи отбирают по контрагенту и смотрят документы в хронологическом порядке. Индекс с доп. упорядочиванием позволит СУБД отдавать страницы списка без полной сортировки.
Второй сценарий — запросы вида ВЫБРАТЬ ПЕРВЫЕ 1 ... УПОРЯДОЧИТЬ ПО Дата УБЫВ с условием по реквизиту. Типичный пример: получить последний документ по контрагенту или последнюю цену товара. Составной индекс позволяет найти ответ почти мгновенно.
Третий сценарий — реквизиты, участвующие в соединениях с последующим упорядочиванием, и поля, по которым часто строятся отчёты с группировкой и сортировкой.
Как выбрать действие
Как включить и проверить результат
Настройка выполняется в конфигураторе. Откройте свойства реквизита объекта (например, документа), найдите свойство «Индексировать» и выберите «Индексировать с доп. упорядочиванием». После сохранения конфигурации потребуется обновление конфигурации базы данных — при этом будет выполнена реструктуризация: платформа создаст новый индекс физически в базе.
На больших таблицах реструктуризация может занять продолжительное время и потребовать монопольного доступа. Планируйте обновление в нерабочее время и обязательно делайте резервную копию перед изменением.
- 1Определите реквизиты, по которым выполняются отборы с упорядочиванием (динамические списки, запросы «первые N»)
- 2В конфигураторе установите для реквизита «Индексировать с доп. упорядочиванием»
- 3Сделайте резервную копию базы
- 4Обновите конфигурацию базы данных, дождитесь реструктуризации
- 5Проверьте скорость проблемных запросов и списков
- 6При необходимости проанализируйте план запроса средствами СУБД или консоли запросов
Проверить эффект можно двумя способами. Первый — замерить время выполнения типичного запроса до и после изменения (например, через замер производительности в конфигураторе). Второй — посмотреть план запроса в СУБД: после включения дополнительного упорядочивания для подходящих запросов должна исчезнуть отдельная операция сортировки, а в плане появится использование нового индекса.
Как проверить результат
Список открывается быстро, прокрутка не подвисает
Время не изменилось — возможно, запрос не использует индекс
Используется индекс по реквизиту, нет отдельной операции Sort
Полное сканирование таблицы или тяжёлая сортировка
Замедление незаметно для пользователей
Запись заметно замедлилась — индексов слишком много
Цена вопроса: чем приходится платить за индексы
Каждый дополнительный индекс увеличивает размер базы и замедляет операции записи: при проведении документа или записи элемента СУБД должна обновить все индексы таблицы. Индекс с дополнительным упорядочиванием больше обычного, так как хранит дополнительные поля ключа.
Поэтому не стоит включать индексирование «на всякий случай» для всех реквизитов. Избыточные индексы — частая причина замедления проведения документов в крупных базах. Оптимальный подход — индексировать только те поля, которые реально участвуют в отборах, соединениях и упорядочиваниях.
Типичные ошибки и ограничения
Частая ошибка — ожидание, что дополнительное упорядочивание ускорит любой запрос по реквизиту. На практике выигрыш появляется только когда вместе с условием по реквизиту есть упорядочивание по ключу записи (дате, ссылке). Если сортировки нет, обычного индекса достаточно, а составной лишь занимает больше места.
Вторая ошибка — индексирование реквизитов с низкой селективностью, например булевых полей или признаков с двумя-тремя значениями. По таким полям индекс почти не помогает: СУБД всё равно читает значительную часть таблицы.
Третья ошибка — забыть, что изменение свойства требует реструктуризации. На файловой базе или при отсутствии монопольного доступа обновление завершится ошибкой, а на большой клиент-серверной базе — надолго заблокирует таблицу.
Альтернативы и дополнительные приёмы
Если проблемный запрос упорядочивает не по ключу записи, а по другому реквизиту, индекс с доп. упорядочиванием не поможет. В этом случае рассмотрите пересмотр самого запроса, использование итогов регистров или денормализацию данных (например, хранение последнего значения в отдельном регистре сведений).
Для ускорения типовых отчётов часто эффективнее правильно спроектировать регистры: в регистрах сведений и накопления индексы по измерениям создаются автоматически, и грамотный выбор измерений решает задачу без ручной настройки индексирования реквизитов.
Перед включением индекса полезно собрать статистику: какие отборы реально используют пользователи в динамических списках. Часто оказывается, что индексировать нужно один-два реквизита, а не все подряд.
Частые вопросы
Чем «Индексировать с доп. упорядочиванием» отличается от обычного «Индексировать»?
Обычный вариант создаёт индекс только по значению реквизита. Вариант с дополнительным упорядочиванием добавляет в индекс ключ записи (дату и ссылку для документов, ссылку для справочников), что ускоряет запросы с одновременным отбором по реквизиту и сортировкой.
Замедлит ли дополнительное упорядочивание запись документов?
Да, любой индекс немного замедляет запись, потому что СУБД обновляет индекс при каждом изменении данных. Составной индекс тяжелее обычного. На практике замедление одного индекса обычно незаметно, но десятки лишних индексов могут ощутимо тормозить проведение.
Нужно ли включать это свойство для стандартных реквизитов?
Стандартные реквизиты (дата, номер, ссылка) уже участвуют в системных индексах платформы. Дополнительные настройки обычно требуются только для прикладных реквизитов, по которым строятся отборы и сортировки.
Можно ли изменить свойство без остановки работы пользователей?
Нет, изменение требует обновления конфигурации базы данных с реструктуризацией, а она выполняется в монопольном режиме. На больших таблицах обновление планируют на нерабочее время.
Как понять, что индекс действительно используется?
Самый надёжный способ — посмотреть план запроса средствами СУБД или через консоль запросов с выводом плана. Если в плане есть поиск по созданному индексу и нет отдельной операции сортировки — настройка работает.
Поможет ли доп. упорядочивание, если сортировка идёт по другому реквизиту?
Нет. Индекс упорядочивает записи только по ключу записи внутри значения реквизита. Если сортировка идёт по третьему полю, СУБД всё равно выполнит отдельную сортировку, и выигрыша не будет.
Что важно запомнить
«Индексировать с доп. упорядочиванием» создаёт составной индекс «значение реквизита + ключ записи» и ускоряет запросы с отбором по реквизиту и сортировкой по дате или ссылке. Включайте его точечно, на копии базы, и подтверждайте эффект планом запроса — избыточные индексы замедляют запись и раздувают базу.