Вопрос оптимизации производительности в 1С:Предприятии неразрывно связан с пониманием работы индексов. Индексы — это специальные структуры в базе данных, которые позволяют СУБД (будь то Microsoft SQL Server, PostgreSQL или файловая база) быстро находить нужные записи, не сканируя всю таблицу целиком. Однако их бездумное применение может привести к обратному эффекту: замедлению записи и неоправданному росту объема базы данных.
В этой статье мы подробно разберем, в каких случаях использование индексов оправдано, проанализируем разницу в режимах индексирования и выясним, как это отражается на технических ресурсах системы.
При настройке свойств реквизита в конфигураторе 1С нам доступны три варианта: «Не индексировать», «Индексировать» и «Индексировать с дополнительным упорядочиванием». Рассмотрим их отличия подробнее.
Простое индексирование создает в СУБД стандартный некластеризованный индекс по значению данного поля. Этого достаточно для ускорения поиска по конкретному значению или фильтрации в запросах.
Индексирование с дополнительным упорядочиванием — это специфический механизм 1С. В этом случае к основному полю в индекс автоматически добавляется ссылка на объект (для справочников и документов) или комбинация периода и номера строки (для регистров). Проанализируем ситуацию: зачем это нужно? Этот режим критически важен для работы динамических списков. Представим, что пользователь сортирует список товаров по цене. Если у сотни товаров цена одинаковая, системе нужно однозначно определить, в каком порядке их выводить на экран. Без дополнительного упорядочивания СУБД пришлось бы выполнять дополнительную сортировку по внутренним идентификаторам, что на больших объемах данных работает крайне медленно.
Рассмотрим основные правила, которыми следует руководствоваться при принятии решения об индексировании:
ГДЕ) или соединения таблиц, индекс необходим.Важно помнить, что платформа 1С уже берет на себя часть работы. Нам не нужно вручную индексировать следующие поля, так как система делает это автоматически:
Ссылка (уникальный идентификатор UUID) — по нему строится основной кластерный индекс.Дата и Номер для документов.Код и Наименование для справочников (если в метаданных включен поиск по коду или наименованию).Многие разработчики опасаются, что база может «распухнуть». Проанализируем, насколько эти опасения оправданы. Индекс — это фактически копия данных реквизита, хранящаяся в структурированном виде (обычно в виде B-дерева). Следовательно, объем занимаемого места напрямую зависит от типа данных:
Индекс по полю типа Дата или Число будет занимать относительно немного места. Однако если мы решим проиндексировать строковое поле длиной в 250 или более символов, размер индекса может быть сопоставим с размером самой таблицы. В практике встречаются случаи (особенно в старых версиях 1С 7.7 на DBF), когда файлы индексов превышали объем самих данных в несколько раз.
Посмотрим на пример ситуации: если у вас есть справочник объемом 500 Мб и вы создаете 10 индексов по различным реквизитам, общий размер базы может легко вырасти до 1.5–2 Гб. В современных СУБД (SQL Server) механизмы сжатия работают эффективнее, но общая зависимость сохраняется.
Главный минус индексов — это замедление операций Insert, Update и Delete. При каждом изменении значения реквизита или добавлении новой строки СУБД обязана обновить все индексы, в которые входит это поле.
Разберем последствия для клиент-серверного варианта: Индексы могут стать причиной избыточных блокировок. Когда транзакция обновляет проиндексированное поле, СУБД блокирует не только саму строку, но и соответствующие узлы в дереве индекса. Это часто приводит к конфликтам («Превышено время ожидания блокировки»), если несколько пользователей одновременно работают с одной таблицей.
В 1С, особенно в регистрах сведений и накопления, активно используются составные индексы. Выясним важную техническую деталь: эффективность такого индекса зависит от порядка полей. Рассмотрим пример индекса по полям: Организация + Склад + Номенклатура.
Этот индекс будет эффективно работать, если в запросе указано:
Организация.Организация и Склад.Однако если вы попытаетесь сделать поиск только по Номенклатуре, этот составной индекс не будет задействован. Это называется правилом левой части. Поиск возможен только начиная с самого первого (лидирующего) поля индекса.
Создать индекс — это только половина дела. В процессе активной эксплуатации данные внутри индекса фрагментируются. Проанализируем, почему это плохо: фрагментация приводит к тому, что логический порядок данных перестает совпадать с физическим, и СУБД приходится совершать больше операций ввода-вывода.
Для поддержания производительности системный администратор или ведущий разработчик должен настроить регламентные задания на SQL-сервере:
Индексирование — мощный инструмент, который нужно применять точечно. Разберем краткий чек-лист перед созданием индекса:
Используя эти правила, мы сможем добиться максимальной производительности системы 1С без неоправданных затрат дискового пространства и ресурсов сервера.