Где хранятся временные таблицы 1с

Как пользоваться таблицей в 1С?

Особенности и недостатки временных таблиц Участников наших курсов часто интересует внутренняя логика работы временных таблиц. Какие критерии индексирования временных таблиц? Где они хранятся? Нужно ли в явном виде их удалять? Ответы на эти вопросы мы рассмотрим в данной статье. Также мы приведем случаи, когда не нужно использовать временные таблицы. Где хранятся временные таблицы? Временные таблицы — это объекты СУБД, никаких временных таблиц на сервере 1С нет, и не путайте их с таблицами значений. Под вопросом: «Где хранятся временные таблицы?» – имеется ввиду физическое расположение, т.е. либо жесткий диск, либо оперативная память. Вероятно, этот вопрос чаще других остается без ответа, либо ответы на него кардинально различаются. Но все сходятся в том, что временные таблицы создаются и хранятся в базе TempDB. Действительно, все временные таблицы относятся к базе данных TempDB, но это вовсе не значит, что они обязательно будут записываться на диск. Правильный ответ на этот вопрос звучит так: все временные таблицы по умолчанию создаются в оперативной памяти, а именно – в буферном кэше. Конечно, есть исключения. Например, если таблица слишком большая, то сервер может принять решение сбросить ее на диск. Также возможна ситуация, когда сервер по каким-либо причинам решил отдать память под другие данные, тогда таблица тоже будет записана на диск. Почему таблица создается именно в памяти? Тут все очевидно – дело в производительности, думаю, не стоит объяснять, что чтение из оперативной памяти гораздо быстрее чтения с диска, даже если этот диск SSD. Проведем эксперимент и проверим, где создается временная таблица. Пишем следующий запрос в консоли: ВЫБРАТЬ 1 КАК Поле1 ПОМЕСТИТЬ ВТ Запускаем трассировку SQL Profiler с событием SQL:BatchComplited, выполняем запрос в консоли и получаем следующий текст SQL запроса: INSERT INTO #tt1 (_Q_001_F_000) SELECT 1.0 Здесь мы видим только заполнение временной таблицы, т.к. код создания временных таблиц в нашей трассировке не отображается. Чтобы понять, где создается временная таблица, необходимо понять, откуда читаются данные – с диска или из памяти. Для этого используем показатель physical reads (количество физических чтений), т.е. сколько 8Кб страниц данных было прочитано с диска для выполнения запроса. Чтобы получить значение этого показателя, необходимо выполнить создание и чтение временной таблицы в Management Studio. Создаем новый запрос и пишем следующее: create table #tt1 (_Q_001_F_000 int); — создаем локальную временную таблицу tt1 INSERT INTO #tt1 (_Q_001_F_000) SELECT 1.0 – заполняем таблицу set statistics io on; — включаем вывод статистики ввода/вывода select * from #tt1 — читаем данные из таблицы set statistics io off; — выключаем вывод статистики drop table #tt1 — удаляем таблицу После выполнения данного кода на закладке «Сообщения» получим следующий текст: (строк обработано: 1) Таблица «#tt1_________________________________________000000000066″. Число просмотров 1, логических чтений 1, физических чтений 0, упреждающих чтений 0, lob логических чтений 0, lob физических чтений 0, lob упреждающих чтений 0. Самое важное здесь то, что данные с диска не читались, т.к. число физических чтений равно 0, при этом есть 1 логическое чтение, т.е. данные были прочитаны только из памяти. Отсюда можно сделать вывод, что временные таблицы в большинстве случаев создаются и хранятся в оперативной памяти, исключения уже описаны выше. Надо ли индексировать временные таблицы? На дисках ИТС, на экзамене 1С: Эксперт, да и я на своих курсах говорю, что нужно индексировать поля условий и соединений во временных таблицах. Эта рекомендация настолько очевидна, что уже практически никто не подвергает ее сомнению. Но как показывает практика, чаще всего индексы во временных таблицах не используются, либо используются, но запрос выполняется еще медленнее, чем без них. Скажу даже больше: для себя я сделал вывод, что польза от индексов на временных таблицах – скорее исключение, чем правило. Это не значит, что индексы не нужно использовать, это значит, что необходимо анализировать каждый конкретный случай, и случаев, когда индекс не нужен, значительно больше. Именно поэтому на курсах по оптимизации постоянно делается акцент на то, что с каждой проблемой надо разбираться отдельно, а не слепо выполнять рекомендации, не понимая, почему эти рекомендации именно такие. Давайте рассмотрим ситуацию с индексацией на примере. Создадим временную таблицу с одним числовым полем и значениями от 1 до 1 млн. Это можно сделать с помощью следующего пакетного запроса: ВЫБРАТЬ 0 КАК Цифра ПОМЕСТИТЬ ВТ_Цифры ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 1 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 2 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 3 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 4 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 5 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 6 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 7 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 8 ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 9 ; ////////////////////////////////////////////////////////////////////////// ВЫБРАТЬ 100000 * Таб6.Цифра + 10000 * Таб5.Цифра + 1000 * Таб4.Цифра + 100 * Таб3.Цифра + 10 * Таб2.Цифра + Таб1.Цифра + 1 КАК Число ПОМЕСТИТЬ ВТ_Числа ИЗ ВТ_Цифры КАК Таб1, ВТ_Цифры КАК Таб2, ВТ_Цифры КАК Таб3, ВТ_Цифры КАК Таб4, ВТ_Цифры КАК Таб5, ВТ_Цифры КАК Таб6 ; ///////////////////////////////////////////////////////////// ВЫБРАТЬ ВТ_Числа.Число ИЗ ВТ_Числа КАК ВТ_Числа ГДЕ ВТ_Числа.Число = 777 Весь запрос выполняется в среднем за 1.2 секунды. Если посмотреть трассировку SQL Profiler, то мы увидим следующее: На создание таблицы уходит 1.1 секунда и еще 0.1 секунда на сканирование всей таблицы, чтобы вернуть нам 1 строку.

Где хранятся временные таблицы 1с

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

Описания временных таблиц хранятся в свойстве запроса МенеджерВременныхТаблиц. К сожалению, в духе 1С, нельзя получить список временных таблиц, которые хранятся в запросе.

Пример, как можно выгрузить временную таблицу в таблицу значений, а заодно и как использовать менеджер временных таблиц:

Готовую таблицу значений из памяти можно выгружать в менеджер временных таблиц запроса. Единственное условие — колонки таблицы значений должны быть типизированными, т.е. иметь тип. Вот пример, демонстрирующий это (спасибо Чепелевич А.А., раньше я думал что это невозможно):

Вместо перечисления списка полей можно использовать «ВЫБРАТЬ *».

От zag2art
Если есть ТЗ, в каждой колонке которой значения всего одного типа, для типизации колонок, можно воспользоваться функцией:
[1с]
Процедура ТипизацияТЗ(ТЗ) Экспорт
РезультатТЗ = новый ТаблицаЗначений;
Для Каждого Колонка из ТЗ.Колонки Цикл
Имя = Колонка.Имя;
МассивТипов = новый Массив(1);
МассивТипов[0] = ТипЗнч(ТЗ[0][Имя]);
Описатель = новый ОписаниеТипов(МассивТипов);
РезультатТЗ.Колонки.Добавить(Имя, Описатель);
КонецЦикла;

Для каждого Строка из ТЗ Цикл
СтрокаРез = РезультатТЗ.Добавить();
ЗаполнитьЗначенияСвойств(СтрокаРез, Строка);
КонецЦикла;

ТЗ = РезультатТЗ.Скопировать();
КонецПроцедуры
[/1с]

Функция для просмотра ВТ в отладчике

Вот как получить список всех ВТ, не знаю. Видимо никак.

Как удалить временную таблицу

Недостатки временных таблиц:</

1. Если в тексте запроса есть временная таблица, то этот запрос не разбирается конструктором запроса (это ограничение можно обойти нештатно, используя объявление подзапроса Книга знаний: v8: Конструирование сложных запросов для 1С). В релизе 8.1.11 можно использовать конструктор
2. Нельзя выполнить запрос над временной таблицей и поместить данные в нее же саму.
3. Нельзя получить список временных таблиц из менеджера временных таблиц.

Примечание: В последних версиях платформы больше 8.1.8 используется синтаксис «ПОМЕСТИТЬ» без предлога «В».

Эти занимательные временные таблицы

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

Мы все их используем

Не важно — новичок Вы или опытный разработчик. Если когда-либо в работе приходилось создавать запросы, то с высокой долей вероятности в них хотя бы раз были использованы временные таблицы. Тот же экзамен “1С:Специалист по платформе” фактически требует их использования при решении задач на экзамене. Сегодня речь будет идти, внезапно, как-раз о временных таблицах и работе платформы 1С с ними.

Мы начнем с простых примеров работы с временными таблицами и действиями платформы на стороне СУБД. А закончим чем-то очень странным и неожиданным.

Примитивный пример

Временные таблицы рекомендуется использовать для создания стабильных и производительных запросов. В тексте запросов их создание выполняется с помощью ключевого слова “ПОМЕСТИТЬ” для пакета запроса.

Здесь в первом пакете запросов мы выбрали первые 100 элементов справочника “Номенклатура” и поместили их во временную таблицу “ВТ_Номенклатура”. После чего во втором пакете мы получили данные из ранее созданной временной таблицы и вернули их как результат выборки. Все просто, не так ли?

Если взглянуть на происходящее на стороне СУБД, то мы увидим следующую серию запросов.

Тоже все относительно просто. Платформа 1С выполняет ряд простых шагов:

Проверка наличия временной таблицы с зарезервированным именем. Если существует, то будет удалена.
Создание временной таблицы.
Далее выполняет запрос из первого пакета для наполнения данных ранее созданной временной таблицы.
Вторым запросом получает данные из временной таблицы для результата выборки.
Очищает данные временной таблицы.

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

Всегда ли платформа действует по таким правилам? Нет. Например, если выполнить этот же запрос еще раз, то количество выполняемых SQL-запросов будет меньше.

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

Также обратите внимание на проверку существования временной таблицы выше. Ранее редко, но метко, можно было нарваться на ошибку уже существующей временной таблицы с именем “#ttN’. Помню такое еще со времен 8.3.6. Теперь это более редкая проблема и это поведение одна из причин изменения ситуации.

Итак, создание временных таблиц выполняется довольно просто. Это относится как в части использования конструкции “ПОМЕСТИТЬ” в запросе, так и в части SQL-запросов платформы 1С. Даже переиспользование ранее созданных временных таблиц не усложняет пример. Но все ли так просто на самом деле?

Серийное производство

Усложним пример и создадим намного больше временных таблиц в запросе. Вот как это выглядит в контексте 1С.

Длинный запрос. В этом примере мы создали 3 временных таблицы, соединили их и результат поместили в четвертую, а после удалили часть временных таблиц и вернули результат. При этом для первых трех таблиц мы добавили индексы. Вот что мы увидим на стороне SQL Server.

Главным отличием от предыдущего примера является большее количество временных таблиц и манипуляций с ними. При этом принципы работы те же самые. Из нового стоит выделить создание индекса для временных таблиц. Фактически, это всегда кластерный индекс по указанному набору полей. Стоит ли всегда создавать индексы на временную таблицу? Если кратко, то “НЕТ”. Добавлять индексы во временную таблицу нужно только при большом объеме данных и только на те поля, которые используются в соединениях или условиях отборов. И если при подготовке к экзаменам Вам говорят, что для временных таблиц всегда нужно добавлять индексы, то скорее всего это только в контексте экзамена.

В этом примере мы также рассмотрели как работает конструкции “УНИЧТОЖИТЬ”. Фактически она также очищает существующую временную таблицу как это делает платформа автоматически при завершении запроса. Давайте пройдем дальше.

Самый лучший менеджер

Настало время еще более сложных примеров. Ранее мы создавали 3 временных таблицы в одном пакетном запросе. Платформе 1С также позволяет использовать менеджер временных таблиц, тем самым сохраняя временную таблицу между вызовами запросов. Этот прием часто используется при наличии сложной логики запросов к базе данных. Как же платформа работает с этим механизмом?

Здесь мы создали менеджер временных таблиц и присвоили его первому объекту запроса. Текст первого запроса написан таким образом, чтобы результат поместить во временную таблицу “ВТ_Номенклатура”. Затем мы создали новый экземпляр запроса и прочитали данные из временной таблицы “ВТ_Номенклатура”, которую сформировали ранее. Обращение к существующей временной таблице как-раз и возможно благодаря менеджеру временных таблиц. В завершении мы очистили все сохраненные данные в контексте менеджера ВТ. На стороне SQL Server это выглядит так.

Фактически, если выполнить все запросы без менеджера временных таблиц одним пакетом, то сформированные SQL-запросы будут те же самые.

Таким образом, с помощью менеджера временных таблиц можно создать один раз временную таблицу и использовать ее в других запросах многократно. Удобно, эффективно, производительно. В типовых конфигурациях это используется повсеместно. Но есть интересные особенности как платформа 1С работает с временными таблицами при многопользовательской работе.

Срывая покровы

Еще несколько очевидных и не очень особенностей работы с временными таблицами.

Контекст и контроль доступности

Как известно, сервер 1С при работе с СУБД имеет пул соединений. Речь идет именно о пуле соединений с СУБД, а не кластером 1С. У Вас может быть 100 активных сеансов работы с информационной базой и 2 запущенных рабочих процесса (rphost’ы), но при этом соединений со SQL Server может быть 15. На каждый рабочий процесс свой пул соединений. Это все очень условно, но смысл должен быть понятен. То есть количество сеансов НЕ равно количеству соединений с базой данных. Использование пула соединений является очень эффективным и производительным подходом и тут все просто отлично.

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

Последнее еще интересней, если рассмотреть это в рамках использования менеджера временных таблиц. Если из кода встроенного языка создать менеджер временных таблиц и выполнять запросы с присвоением этого менеджера ВТ объекту запроса, то можно быть уверенным, что все они будут выполнены в рамках одного соединения с СУБД.

Тут может показаться, что если в разных сеансах 1С создать менеджер временных таблиц, а в нем сохранить временную таблицу с одним названием, допустим, “ВТ_Номенклатура”, то эта таблица будет доступна в разных сеансах, если они используют одно соединение с СУБД. На самом деле нет, т.к. платформа еще и сама контролирует доступность временных таблиц в разрезе сеансов и доступность в зависимости от контекста.

Во втором сеансе будет ошибка:

И это логично. Дело даже не в том, что это разные сеансы, а в том что это разные менеджеры временных таблиц. Использовать один менеджер временных таблиц в разных сеансах платформа не позволяет, а контроль доступности осуществляется именно в контексте менеджера ВТ.

Кэширование

Вы когда-нибудь кэшировали менеджер временных таблиц? В некоторых особых случаях Вы могли бы увидеть вот это.

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

Как этого избежать? Нужно следовать простым правилам:

НЕ кэшировать менеджер временных таблиц там, где кэш сохраняется между вызовами сервера.
Быть осторожным с циклическими ссылками. В принципе, это относится не только к менеджеру ВТ, но и к любой разработке.
Вместо кэширования менеджера ВТ подумать над архитектурой. * Возможно кэшируемые в ВТ данные требуют особого хранения в базе для быстрого доступа.

Вот даже с таким можно встретиться.

Утопи меня в соединениях

И еще один эксперимент. Для каждого менеджера ВТ резервируются соединения с СУБД. Это мы уже говорили. Но это не значит, что на каждый созданный менеджер создается соединение с базой данных. Для эксперимента выполните в одном сеансе вот такой код.

Мы создали 10000 новых временных таблиц и менеджеров ВТ! Вы можете это проверить и на стороне СУБД с помощью скриптов, предложенных в конце статьи. Там же есть и скрипты для просмотра количества соединений с сервером баз данных. При этом новых соединений на каждый менеджер ВТ платформа не создала. Все потому что для обслуживания одного сеанса достаточно одного соединения с базой данных. Возможно, для этого правила есть исключения, но мы их сейчас рассматривать не будем.

Как сервер 1С заставить создать дополнительные соединения с БД? Откройте 10 сеансов 1С и запустите этот код в каждом сеансе. Барабанная дробь! Сервер 1С увеличит пул соединений с СУБД до 10 сеансов (может и больше, если ранее соединения уже были созданы). При этом стоит заметить, что пул соединений увеличивается не сразу после старта сеанса 1С, а именно во время создания менеджеров временных таблиц в каждом сеансе. Главное запустить этот код параллельно.

Таким образом, использование временных таблиц и менеджера ВТ может напрямую влиять на размер пула соединений сервера 1С с сервером баз данных.

Только не устраивайте этот спам временными таблицами на рабочем окружении. Поберегите сервер!

Покажи мне свой товар

Как мы уже говорили ранее, локальная временная таблица (именно такие используются платформой 1С) на уровне СУБД доступны только тому соединению, в рамках которого она была создана. Мы никак не можем прочитать из одного соединения содержимое таблиц другого соединения. Например, Вы с помощью диагностических запросов нашли, что таблица “#tt555” участвует в подозрительном запросе и захотели посмотреть что в ней находится. Но SQL Server не позволит это сделать. Но, как говорится, если сильно хочется, то можно. И вот как!

Для наглядности мы будем немного изменять тексты запросов, которые генерирует платформа. Это только для наглядности. Все что Вы увидите ниже можно применять и на практике. И так, допустим платформа создала временную таблицу и наполнила ее данными во таким способом.

С помощью этого скрипта мы можем узнать где именно эта временная таблица хранится в базе TempDB вплоть до адреса страниц в файле базы данных.

Предположим, что результат мы получили следующий.

Имя временной таблицы	Идентификатор объекта	Тип данных	Адрес первой страницы	Количество страниц с данными	Количество записей в таблице
#ttTest______00000000EAFD	-1137577394	IN_ROW_DATA	0x481E01000800	1	1

Очень интересно 🙂 Но что же это значит? Расшифруем.

Имя временной таблицы (name) — это полное имя временной таблицы с учетом идентификатора соединения с базой данных. Именно благодаря такому формированию имени можно создавать временные таблицы с одинаковым именем в разных сессиях, т.к. по факту имена у них все же будут отличаться. Хоть последнее и не будет заметно при их использовании.
Идентификатор объекта (object_id) — идентификатор объекта временной таблицы.
Тип данных (type_desc) — какие данные хранятся в этом объекте. В нашем случае это таблица с записями.
Адрес первой страницы (first_page) — адрес первой страницы. Это важная часть нашего эксперимента. В нашем случае это значение “0x481E01000800”. Сохранен в виде 6 байтового значения, где каждый байт представлен двумя шестнадцатеричными символами. Для расшифровки нужно читать его справа на лево. Если его расшифровать, то получим следующее (для конвертации hex в число можно использовать этот сервис):
- 00 08 — это идентификатор файла базы данных TempDB, где эта таблица сохранения. В нашем случае это 8.
- 00 01 1E 48 — это идентификатор начальной страницы. В нашем случае это 73288.
Количество страниц с данными (data_pages) — сколько страниц по 8 КБ занимает таблица.
Количество записей в таблице (rows) — сколько записей во временной таблице.

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

В ответ мы получили большое количество записей. Вот последние 8. Остальные записи вида “BUFFER:” и “PAGE HEADER:” нас не интересуют, сразу перейдем к данным.

ParentObject	Object	Field	VALUE
Slot 0 Offset 0x60 Length 119	Memory Dump @0x0000003EC487A060	0000000000000000: 30001400 811fa45d 36c581e4 11e8f9dc d58ab12f 0….¤]6Åä.èùÜÕŠ±/
Slot 0 Offset 0x60 Length 119	Memory Dump @0x0000003EC487A060	0000000000000014: 02000001 0077002d 0442043e 04420420 00420435 …..w.-.B.>.B. .B.5
Slot 0 Offset 0x60 Length 119	Memory Dump @0x0000003EC487A060	0000000000000028: 043a0441 04420420 0034043e 043b0436 0435043d . A.B. .4.>.;.6.5.=
Slot 0 Offset 0x60 Length 119	Memory Dump @0x0000003EC487A060	000000000000003C: 04200032 04380434 04350442 044c0420 0042043e . .2.8.4.5.B.L. .B.>
Slot 0 Offset 0x60 Length 119	Memory Dump @0x0000003EC487A060	0000000000000050: 043b044c 043a043e 04200030 0434043c 0438043d .;.L. >. .0.4.<.8.=
Slot 0 Offset 0x60 Length 119	Memory Dump @0x0000003EC487A060	0000000000000064: 04380441 04420440 04300442 043e0440 042100 .8.A.B.@.0.B.>.@.
Slot 0 Offset 0x60 Length 119	column1 = [Binary data] Slot 0 Column 1 Offset 0x4 Length 16 Length (physical) 16	0000003EC487A064: 811fa45d 36c581e4 11e8f9dc d58ab12f .¤]6Åä.èùÜÕŠ±/
Slot 0 Offset 0x60 Length 119	Slot 0 Column 2 Offset 0x1b Length 92 Length (physical) 92	column2	Этот текст должен видеть только администратор!

В предпоследней строке с описанием “column1 = [Binary data] Slot 0 Column 1 Offset 0x4 Length 16 Length (physical) 16” содержится значение идентификатора в первой колонке “811fa45d 36c581e4 11e8f9dc d58ab12f”. В последней строке с описанием “Slot 0 Column 2 Offset 0x1b Length 92 Length (physical) 92” содержится значение второй колонки “Этот текст должен видеть только администратор!”.

Дело сделано! Мы прочитали содержимое временной таблицы другой сессии. Да, это не очень удобно в таком виде получать содержимое таблицы с большим количеством записей. Но здесь был продемонстрирован принцип, а инструменты для удобства можно создавать отдельно. Также есть и еще одно важное ограничение: использовать служебную процедуру “PAGE” можно только с правами “sysadmin”. Это стоит учитывать в работе. То есть этот способ доступен только для администратора или разработчика с соответствующими правами.

И немного диагностики

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

Временные таблицы 1С

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

Временные таблицы в 1С

Временные таблицы — это объекты СУБД, никаких временных таблиц на сервере 1С нет, не путайте пожалуйста, их с таблицами значений.

Временные таблицы хранятся в объекте типа МенеджерВременныхТаблиц. Когда этот объект уничтожается, уничтожаются и временные таблицы.

Физически временные таблицы по умолчанию создаются в оперативной памяти, а именно в буферном кэше.

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

Почему таблица создается именно в памяти? Тут все очевидно, дело в производительности, думаю не стоит объяснять, что чтение из оперативной памяти гораздо быстрее чтения с диска, даже если этот диск SSD.
Чтобы создать временную таблицу, используется ключевое слово «ПОМЕСТИТЬ», например:

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

Готовую таблицу значений из памяти можно выгружать в менеджер временных таблиц запроса. Единственное условие – колонки таблицы значений должны быть типизированными, т.е. иметь тип. Вот пример, демонстрирующий это:

Вместо перечисления списка полей можно использовать “ВЫБРАТЬ *”.

Если есть ТЗ, в каждой колонке которой значения всего одного типа, для типизации колонок, можно воспользоваться функцией:

Где хранятся временные таблицы 1с

Как пользоваться таблицей в 1С?