IT-КУБиК-Сервис • Форум 1С
Абстрактный тёмно-синий фон с мягкими геометрическими линиями и оранжевыми акцентами, создающий технологичную атмосферу

Агрегатор публикаций с Инфостарта по 1С:Предприятие — обработки, расширения, конфигурации, интеграции и администрирование. Сообщество специалистов 1С.

Оптимизация запросов с временными таблицами в 1С

Временная таблица в 1С позволяет сохранить промежуточный результат запроса и обращаться к нему повторно. Инструмент полезен, когда сложный отчёт несколько раз использует один набор строк, а исходные данные требуют дорогого соединения, группировки или фильтрации. Однако материализация не обеспечивает автоматического ускорения: результат зависит от структуры запроса и объёма данных.

Чаще всего выигрыш появляется при подготовке небольшой выборки товаров, клиентов или документов, после которой с ней работают несколько подзапросов. Временная таблица может зафиксировать промежуточный срез и упростить вычисление итогов. Если же выборка сразу возвращается пользователю, дополнительная запись и чтение способны сделать запрос медленнее.

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

Когда временная таблица ускоряет запрос

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

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

Как построить промежуточный результат

Управляемая временная таблица создаётся командой ПОМЕСТИТЬ непосредственно в языке запросов. Она существует в пределах одного запроса, после чего платформа освобождает занимаемые ресурсы. Такую таблицу можно использовать в соединениях, подзапросах и агрегатах, сохраняя привычный синтаксис 1С.

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

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

Контроль объёма и ресурсов

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

На управляемой временной таблице нельзя рассчитывать на постоянные индексы исходных регистров. Физические временные таблицы СУБД допускают индексацию, но её реализация зависит от используемой СУБД и управления соединениями. Перед применением решения администратору следует проверить параметры временного хранилища и доступную оперативную память.

Дополнительные ориентиры по нагрузке и инфраструктуре дают практические обзоры. Их полезно сопоставлять с наблюдаемыми метриками конкретной базы, поскольку рекомендации для одной СУБД нельзя без проверки переносить на другую.

Проверка изменений и типичные ошибки

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

Временная таблица не исправляет логические ошибки. Например, конструкция ОБЪЕДИНИТЬ удаляет совпадающие строки, а ПЕРВЫЕ меняет смысл отчёта, если порядок не определён. Лишние соединения и вычисление итогов до фильтрации также остаются проблемными. Перед материализацией следует убрать лишние поля и перенести условия отбора как можно ближе к источнику.

Физическая временная таблица требует дополнительного контроля. Её данные связаны с соединением и транзакцией, поэтому pooled-соединение, откат или перенос вызова могут изменить ожидаемое поведение. Нужны явное удаление таблицы, проверка прав доступа и тестирование в контексте управляемых приложений 1С.

Практические рекомендации и следующий шаг

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

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

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