← На главную

Вопрос индексации в 1С — это не просто техническая деталь, а фундамент производительности любой крупной системы. Часто начинающие разработчики сталкиваются с дилеммой: индексировать всё подряд или надеяться на оптимизатор СУБД. В рамках этой статьи мы подробно разберем, когда создание индекса действительно ускоряет работу, как СУБД обрабатывает различные виды соединений и какие нюансы стоит учитывать при работе с временными таблицами.

Определяем порог целесообразности: со скольких строк начинать?

Разберем ситуацию, которая часто вызывает споры: нужно ли индексировать таблицу, если в ней всего 4500 записей? Или, может быть, 100? В среде экспертов 1С существует эмпирическое правило: задумываться об индексации стоит, когда количество строк во временной таблице превышает 100–1000 записей.

Почему именно так? Проанализируем процесс: создание индекса — это не бесплатная операция. СУБД тратит время на построение дерева индекса, выделение места в tempdb и обновление системных статистик. Если данных мало, СУБД быстрее выполнит полное сканирование таблицы (Table Scan) в оперативной памяти, чем будет тратить ресурсы на работу с индексом. Однако для таблиц свыше 1000 строк отсутствие индекса может привести к катастрофическому падению производительности при соединениях.

Как вид соединения влияет на выбор полей для индексации

Рассмотрим, какие поля и в каких таблицах нужно индексировать в зависимости от типа связи. Важно помнить, что в 1С порядок таблиц в запросе имеет значение для читаемости, но СУБД (SQL Server или PostgreSQL) может перестроить план выполнения по-своему.

1. Левое соединение (LEFT JOIN): Проанализируем классический случай. У нас есть основная таблица (левая) и присоединяемая (правая). Чаще всего индексировать нужно поля связи в правой (присоединяемой) таблице. Это позволяет СУБД для каждой строки из левой таблицы мгновенно находить соответствие в правой.
2. Правое соединение (RIGHT JOIN): Как мы выяснили, платформа 1С и большинство оптимизаторов «волшебным образом» превращают правое соединение в левое, просто меняя таблицы местами. С точки зрения производительности разницы нет, но для соблюдения стандартов разработки 1С рекомендуется всегда использовать ЛЕВОЕ СОЕДИНЕНИЕ, так как оно легче воспринимается человеком.
3. Полное соединение (FULL JOIN): Это самый тяжелый тип связи. Здесь желательно иметь индексы по полям соединения в обеих таблицах. Это даст СУБД шанс использовать алгоритм Merge Join, который является наиболее эффективным для больших объемов данных.
4. Соединение со Срезами Последних: Выясним важный нюанс. Виртуальные таблицы (например, РегистрСведений.ИмяРегистра.СрезПоследних) превращаются в сложные подзапросы. Если вы соединяете временную таблицу с таким срезом, обязательно проиндексируйте поле связи во временной таблице. Это поможет оптимизатору эффективнее ограничить выборку из итогов регистра.

Алгоритмы соединения и роль индекса

Чтобы понимать, зачем мы ставим «галочку» индексации, разберем, что происходит «под капотом» СУБД. Оптимизатор выбирает один из трех основных методов соединения:

1. Вложенные циклы (Nested Loops). Рассмотрим ситуацию: одна таблица очень маленькая, а вторая — огромная. СУБД берет строку из маленькой таблицы и ищет её в большой. Если большая таблица проиндексирована по полю связи, поиск происходит мгновенно (Index Seek). Если индекса нет, СУБД придется каждый раз сканировать всю огромную таблицу целиком, что приведет к зависанию запроса.

2. Соединение слиянием (Merge Join). Этот метод требует, чтобы обе таблицы были заранее отсортированы по полям связи. Поскольку индекс в 1С — это и есть физически отсортированные данные, наличие индексов на обеих таблицах позволяет СУБД просто «пройтись» по двум спискам одновременно. Это самый быстрый способ для соединения миллионных таблиц.

3. Хеш-соединение (Hash Join). Используется, когда индексов нет. СУБД строит в памяти хеш-таблицу. Проанализируем риск: если данных много и памяти не хватит, СУБД начнет сбрасывать данные на диск (в tempdb), что замедлит работу в десятки раз. Индексация помогает избежать этого сценария.

Покрывающие индексы: как читать данные, не обращаясь к таблице

Посмотрим на продвинутый прием. В сообщении №6 упоминалось, что чтение некластерного индекса быстрее, чем кластерного. Если ваш индекс во временной таблице содержит не только поля связи, но и те поля, которые вы выбираете в секции ВЫБРАТЬ, СУБД вообще не будет обращаться к самой таблице. Она возьмет все нужные данные прямо из «листьев» индекса. В 1С это достигается созданием индекса по нескольким полям в правильном порядке.

Борьба с Table Spool

Выясним, что такое Table Spool и как индексы помогают от него избавиться. Иногда в плане запроса можно увидеть операцию «Spool» — это временное сохранение промежуточных результатов на диск, потому что СУБД «боится» потерять результат вычисления сложного подзапроса. Индексация полей соединения во временных таблицах — это основной инструмент разработчика, позволяющий подсказать оптимизатору, что данные уже упорядочены и доступны, избавляя систему от лишней нагрузки на дисковую подсистему. Для выявления подобных проблем и оценки нагрузки можно использовать инструмент для анализа SQL-сервера и выполняемых запросов.

Практические рекомендации по созданию индексов

Разберем по шагам, как эффективно индексировать временные таблицы в пакете запросов:

1. Не индексируйте всё подряд. Каждый индекс замедляет выполнение первого запроса в пакете (того, который создает временную таблицу).
2. Соблюдайте порядок полей. Если вы делаете соединение по полям Склад и Номенклатура, индекс должен быть именно в таком порядке (или наоборот), но обязательно содержать оба поля. Если вы проиндексируете только Склад, а соединять будете по Номенклатуре, индекс не сработает.
3. Используйте индексацию для исключения дублей. При создании индекса во временной таблице в 1С можно указать условие уникальности, что дополнительно защитит вашу логику от неожиданных «размножений» строк при соединениях.
4. Проверяйте планы запросов. Если запрос работает медленно, используйте консоль запросов с просмотром плана выполнения. Ищите операции Table Scan (полное сканирование) на больших объемах — это главный сигнал к тому, что индекс необходим.

Проанализировав вышесказанное, мы видим, что индексация — это инструмент точечной настройки. Используйте её осознанно для таблиц с объемом более 100-500 строк и всегда отдавайте приоритет индексации тех полей, которые участвуют в секции ГДЕ и ПО (условия соединения).