Временные таблицы в 1С: где хранятся и как устроены

Временные таблицы в 1С — это промежуточные наборы данных, которые создаются внутри запроса и существуют только в рамках сеанса работы менеджера временных таблиц. Они не записываются в основную базу данных как объекты метаданных: в клиент-серверном режиме платформа размещает их в служебной области СУБД (в MS SQL Server — в системной базе tempdb, в PostgreSQL — во временном табличном пространстве), а в файловом режиме — в оперативной памяти или во временных файлах рабочего процесса.

Понимание того, где физически живут временные таблицы, важно по двум причинам. Во-первых, это объясняет их ограничения: они недоступны другим сеансам, исчезают при завершении работы менеджера и не видны в структуре базы через конфигуратор. Во-вторых, это помогает диагностировать проблемы производительности: разросшаяся tempdb на сервере СУБД почти всегда указывает на запросы с большими временными таблицами без индексов.

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

Как платформа 1С создаёт и размещает временные таблицы

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

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

Где хранятся временные таблицы в клиент-серверном режиме

В клиент-серверном варианте работы временные таблицы физически размещаются на сервере СУБД, а не на сервере 1С и не на клиенте. Конкретное место зависит от используемой СУБД.

В MS SQL Server временные таблицы попадают в системную базу tempdb. Именно поэтому администраторы наблюдают рост tempdb при тяжёлых отчётах: каждая таблица из ПОМЕСТИТЬ — это реальная таблица в tempdb с данными и, при наличии индекса, индексом. В PostgreSQL платформа создаёт временные таблицы уровня сеанса, которые хранятся во временном табличном пространстве и автоматически удаляются при завершении соединения. В IBM Db2 и Oracle используются аналогичные механизмы временных таблиц соответствующей СУБД.

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

Где хранятся временные таблицы в файловом режиме

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

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

Как явно управлять временем жизни временных таблиц

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

МенеджерВТ = Новый МенеджерВременныхТаблиц;

Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = МенеджерВТ;
Запрос.Текст =
"ВЫБРАТЬ Товары.Ссылка КАК Номенклатура
|ПОМЕСТИТЬ ВТ_Товары
|ИЗ Справочник.Номенклатура КАК Товары
|ГДЕ НЕ Товары.ПометкаУдаления
|ИНДЕКСИРОВАТЬ ПО Номенклатура";
Запрос.Выполнить();

// второй запрос видит ВТ_Товары, т.к. менеджер общий
Запрос2 = Новый Запрос;
Запрос2.МенеджерВременныхТаблиц = МенеджерВТ;
Запрос2.Текст = "ВЫБРАТЬ * ИЗ ВТ_Товары КАК Т";

Если временная таблица больше не нужна до конца работы менеджера, её стоит удалить явно конструкцией УНИЧТОЖИТЬ ВТ_Товары. Это освобождает место в tempdb и снижает нагрузку на СУБД, особенно в длинных цепочках запросов.

1. 1
   Создайте объект МенеджерВременныхТаблиц и сохраните его в переменной
2. 2
   Назначьте менеджер каждому запросу пакета через свойство МенеджерВременныхТаблиц
3. 3
   Выполните запросы с ПОМЕСТИТЬ, добавляя ИНДЕКСИРОВАТЬ ПО по полям соединений
4. 4
   Используйте временные таблицы в последующих запросах того же менеджера
5. 5
   Уничтожьте ненужные таблицы командой УНИЧТОЖИТЬ или дождитесь закрытия менеджера

Чем временные таблицы отличаются от таблиц значений

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

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

Производительность: индексы, объём и контроль tempdb

Главное правило оптимизации — добавлять ИНДЕКСИРОВАТЬ ПО по полям, которые участвуют в соединениях временной таблицы с другими данными. Без индекса СУБД сканирует временную таблицу целиком при каждом соединении, что на больших объёмах даёт кратное замедление.

Второе правило — помещать во временную таблицу только нужные поля и строки. Фильтрацию лучше выполнять до ПОМЕСТИТЬ, а не после: чем меньше таблица, тем меньше нагрузка на tempdb и тем быстрее соединения. Соединение двух больших временных таблиц между собой — отдельный источник проблем; часто выгоднее соединять временную таблицу с физической таблицей базы.

Как проверить, что временные таблицы работают корректно

Простейшая проверка — выполнить запрос ВЫБРАТЬ * ИЗ ВТ_Имя с тем же менеджером и посмотреть число строк. Если возвращается ошибка «таблица не найдена», значит, менеджеры у запросов разные. Если строк ноль — фильтр при помещении отсек все данные.

На уровне СУБД в MS SQL Server можно наблюдать рост tempdb во время выполнения тяжёлого отчёта: резкий скачок с последующим неосвобождением места обычно означает, что временные таблицы не уничтожаются в коде, а менеджеры живут дольше необходимого. В консоли запросов или через технологический журнал полезно смотреть план запроса: наличие сканирований там, где ожидался поиск по индексу, указывает на пропущенный ИНДЕКСИРОВАТЬ ПО.

Частые вопросы