Почему 1С не всегда выполняет CREATE TABLE для временных таблиц?

При анализе технологического журнала или трассировки SQL Server разработчики часто сталкиваются с ситуацией, когда платформа 1С выполняет инструкцию INSERT INTO для временной таблицы (например, #tt1), но при этом в логах отсутствует предшествующая ей команда CREATE TABLE. На первый взгляд это может показаться ошибкой или странным поведением системы. Однако на самом деле мы имеем дело с глубоко продуманным механизмом оптимизации работы с СУБД. В этой статье мы подробно разберем, как именно платформа управляет временными объектами и почему повторное использование таблиц критически важно для производительности.

Механизм кэширования структур временных таблиц

Давайте проанализируем, что происходит на уровне взаимодействия между сервером приложений 1С и SQL Server. Платформа 1С стремится минимизировать количество операций с метаданными. Создание (CREATE TABLE) и удаление (DROP TABLE) объектов — это тяжелые операции для СУБД, так как они требуют внесения изменений в системные таблицы базы данных tempdb и вызывают блокировки системного каталога.

Для оптимизации этого процесса платформа использует алгоритм кэширования, который работает следующим образом:

1. Проверка сигнатуры таблицы: Когда в коде 1С выполняется запрос, использующий МенеджерВременныхТаблиц или временные таблицы в рамках одного пакета, платформа сначала проверяет текущее соединение с СУБД. Она ищет, не была ли ранее в этом же соединении создана таблица с точно такой же структурой (количество колонок, их типы данных, длина и точность).
2. Повторное использование: Если в текущем сеансе SQL Server уже существует «пустая» временная таблица, подходящая под описание, 1С принимает решение не создавать новую. Вместо этого она просто переиспользует уже существующий объект.
3. Очистка данных: Чтобы данные из предыдущих вызовов не перемешались с новыми, платформа выполняет быструю очистку таблицы. Чаще всего в трассе SQL вместо CREATE TABLE мы увидим команду TRUNCATE TABLE или DELETE FROM. Это значительно быстрее, чем полное пересоздание структуры.

Роль пула соединений и Менеджера временных таблиц

Важно понимать, как на этот процесс влияет архитектура 1С. Рассмотрим ситуацию подробнее: сервер приложений поддерживает пул соединений с базой данных. Одно и то же физическое соединение SQL может последовательно обслуживать запросы разных пользователей. Если пользователь «А» завершил работу с запросом, в котором была временная таблица, и его соединение вернулось в пул, то при поступлении запроса от пользователя «Б» (если он попадет в то же соединение) платформа может обнаружить оставшуюся структуру таблицы.

Объект МенеджерВременныхТаблиц в программном коде 1С управляет временем жизни этих таблиц с точки зрения логики приложения, но на уровне SQL-сервера платформа оставляет за собой право «придержать» таблицу в tempdb для будущих нужд.

Проанализируем пример того, как это выглядит в коде 1С:

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

Если этот код выполняется многократно в высоконагруженной системе, мы заметим, что CREATE TABLE #tt1 выполнится лишь один раз (при первом обращении в рамках конкретного соединения), а во все последующие разы платформа будет сразу переходить к заполнению таблицы.

Проблема TempDB Contention и ее решение

Почему эта оптимизация так важна? Выясним причину, заглянув во внутреннее устройство SQL Server. В базе данных tempdb существуют специальные страницы управления распределением пространства — GAM (Global Allocation Map), SGAM (Shared Global Allocation Map) и PFS (Page Free Space). При частом создании и удалении временных таблиц сотнями сессий одновременно возникает конкуренция за доступ к этим страницам (так называемый TempDB Contention).

Благодаря тому, что 1С не выполняет CREATE TABLE каждый раз:

• Снижается нагрузка на системные защелки (latches) в tempdb.
• Уменьшается объем лога транзакций, так как TRUNCATE практически не логируется по сравнению с операциями изменения метаданных.
• Ускоряется компиляция планов запросов, поскольку SQL-серверу проще работать с уже известным объектом.

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

Рассмотрим ситуацию, когда мы используем индексирование. Если в запросе 1С указано ИНДЕКСИРОВАТЬ ПО..., платформа также пытается оптимизировать работу с индексами. Если кэшированная таблица уже имеет необходимые индексы, они будут переиспользованы. Если же структура совпадает, но индексы другие, платформа может выполнить команду CREATE INDEX отдельно, не затрагивая саму таблицу. Это еще раз подтверждает гибкость алгоритма оптимизации.

Когда таблица всё же будет удалена?

Не стоит думать, что временные таблицы остаются в базе вечно. Разберем случаи, когда платформа всё-таки выполнит DROP TABLE:

1. Разрыв соединения: При закрытии сеанса или перезапуске рабочего процесса rphost все временные таблицы, связанные с данными соединениями, уничтожаются SQL-сервером автоматически.
2. Очистка пула: Платформа может принудительно очистить кэш структур, если их становится слишком много.
3. Изменение структуры: Если тип данных хотя бы в одной колонке изменился (например, увеличилась длина строки в конфигурации), старая кэшированная таблица больше не подойдет по сигнатуре, и 1С создаст новую.

Как это отслеживать

Для тех, кто хочет убедиться в этом поведении самостоятельно, рекомендуем запустить SQL Server Profiler или использовать Расширенные события (Extended Events). Обратите внимание на события SP:StmtStarting или SQL:StmtStarting. Вы увидите, что перед операцией INSERT часто проскакивает быстрая команда очистки, но отсутствует создание. Это верный признак того, что платформа успешно применила оптимизацию повторного использования структуры.

Подводя итог, можно сказать, что отсутствие CREATE TABLE — это не повод для беспокойства, а свидетельство эффективной работы механизмов платформы 1С по снижению нагрузки на серверную инфраструктуру.