Временные таблицы в запросах 1С 8.3

Временная таблица

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

Создается временная таблица с помощью ключевого слова ПОМЕСТИТЬ:

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

При создании новой временной таблицы она не сохраняется в базе данных. В файловой базе временные таблицы хранятся в оперативной памяти, в MS SQL Server в специальной служебной базе TempDB.

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

Но у временных таблиц есть и свои минусы:

Менеджер временных таблиц

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

Создать менеджер временных таблиц можно с помощью конструктора:

Источник

Использование временных таблиц

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

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

2. Есть ситуации, когда временные таблицы не следует создавать или создание временных таблиц необходимо минимизировать.

2.1. Не следует создавать временные таблицы с очень большим объемом данных (сотни тысяч записей). Иначе это приведет к существенному снижению производительности при записи и исчерпанию свободного места на диске. Если алгоритму требуется работать с большим объемом данных, то он должен выполнять обработку этих данных порциями.

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

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

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

2.5. Не следует копировать одну временную таблицу в другую только ради того, чтобы переименовать первую таблицу во вторую. Вместо этого, следует передавать имя таблицы.

3. Временные таблицы следует всегда индексировать, когда это даст прирост производительности.

3.1. Индекс следует строить если:

3.2. Маленькие временные таблицы индексировать не нужно (менее 1000 записей).

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

Источник

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

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

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

Для всех примеров и экспериментов использовалась платформа 1С:Предприятие 8.3.16.1063 в клиент-серверном режиме работы. В качестве СУБД выступал SQL Server 2017. Для изучения действий платформы использовались следующие инструменты:

Интересно? Добро пожаловать!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кэширование

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

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

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

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

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

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

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

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

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

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

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

Другие заметки

Есть другие важные темы, связанные с использованием временных таблиц. Кратко упомяну о них, т.к. в статье рассматривать все темы просто невозможно:

А теперь перейдем к чему-нибудь неожиданному.

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

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

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

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

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

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

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

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

В предпоследней строке с описанием » 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». Это стоит учитывать в работе. То есть этот способ доступен только для администратора или разработчика с соответствующими правами.

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

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

Источник

3 главных вопроса про временные таблицы 1С

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

Участников наших курсов часто интересует внутренняя логика работы временных таблиц.

Какие критерии индексирования временных таблиц? Где они хранятся? Нужно ли в явном виде их удалять?

Ответы на эти вопросы мы рассмотрим в данной статье.

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

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

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

Под вопросом: «Где хранятся временные таблицы?» – имеется ввиду физическое расположение, т.е. либо жесткий диск, либо оперативная память.

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

Но все сходятся в том, что временные таблицы создаются и хранятся в базе TempDB.

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

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

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

Почему таблица создается именно в памяти? Тут все очевидно – дело в производительности, думаю, не стоит объяснять, что чтение из оперативной памяти гораздо быстрее чтения с диска, даже если этот диск SSD.

Проведем эксперимент и проверим, где создается временная таблица.

Пишем следующий запрос в консоли:

Запускаем трассировку SQL Profiler с событием SQL:BatchComplited, выполняем запрос в консоли и получаем следующий текст SQL запроса:

Здесь мы видим только заполнение временной таблицы, т.к. код создания временных таблиц в нашей трассировке не отображается.

Чтобы понять, где создается временная таблица, необходимо понять, откуда читаются данные – с диска или из памяти. Для этого используем показатель physical reads (количество физических чтений), т.е. сколько 8Кб страниц данных было прочитано с диска для выполнения запроса.

Чтобы получить значение этого показателя, необходимо выполнить создание и чтение временной таблицы в Management Studio.

Создаем новый запрос и пишем следующее:

После выполнения данного кода на закладке «Сообщения» получим следующий текст:

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

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

Надо ли индексировать временные таблицы?

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

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

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

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

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

Давайте рассмотрим ситуацию с индексацией на примере.

Создадим временную таблицу с одним числовым полем и значениями от 1 до 1 млн.

Это можно сделать с помощью следующего пакетного запроса:

Весь запрос выполняется в среднем за 1.2 секунды.

Если посмотреть трассировку SQL Profiler, то мы увидим следующее:

На создание таблицы уходит 1.1 секунда и еще 0.1 секунда на сканирование всей таблицы, чтобы вернуть нам 1 строку.

Давайте посмотрим, что изменится, если добавить индекс в таблицу ВТ_Числа.

На моем компьютере запрос стал выполняться в среднем за 6 секунд.

Время создания таблицы увеличилось с 1 секунды до 5.3, при этом даже поиск по индексу в таблице все равно происходит медленнее, чем сканирование: 0.5 сек. против 0.1 без индекса. Единственное, в чем этот запрос выигрывает, — немного меньше логических чтений: 2057 против 2233 при сканировании.

Используйте индексирование только в том случае, если вы видите от этого явный положительный эффект.

Надо ли явно удалять временные таблицы после создания?

Ответ будет зависеть от способа создания временной таблицы.

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

В данном случае MS SQL создает локальную временную таблицу с одной решеткой (#), например #tt1.

Как только пакетный запрос завершается, неявный МВТ закрывается, и автоматически последует команда «Truncate table», которая удаляет созданную таблицу.

Если временная таблица проиндексирована, то сначала будет удален индекс и только потом таблица.

Пример можно посмотреть выше в трассировке.

В данном случае нет необходимости использовать команду «УНИЧТОЖИТЬ», только если Вы не хотите создать в том же запросе новую таблицу с таким же именем, ну или считаете это хорошим стилем написания кода.

Здесь главное понимать, что таблица все равно будет удалена при завершении пакетного запроса.

Ситуация меняется, если Вы явно используете менеджер временных таблиц (МВТ), т.е. создаете соответствующий объект метаданных. В этом случае MS SQL создает глобальную временную таблицу с двумя решетками (##).

Такая таблица будет удалена в любом из следующих вариантов:

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

Подведем итог: если Вы не используете МВТ, то явно удалять временную таблицу не требуется, она будет удалена после завершения пакетного запроса.

Если явное объявление МВТ используется, то рекомендуется удалить таблицу вручную, например, в запросе командой «Уничтожить», либо методом МВТ.Закрыть().

Минусы временных таблиц

Идеальных инструментов не бывает, тем более в мире 1С.

Давайте рассмотрим, какие проблемы может принести активное использование временных таблиц.

Чрезмерное разрастание базы TempDB

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

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

Для исправления ситуации необходимо выполнить следующие команды:

Чрезмерное упрощение запросов

Нельзя сказать, что это очень большой минус, но все же.

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

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

Если можно написать оптимальный запрос без использования временных таблиц, то лучше обойтись без них.

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

Заключение

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

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

Бурмистров Андрей

PDF-версия статьи для участников группы ВКонтакте

Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.

Статья в PDF-формате

Вы можете скачать эту статью в формате PDF по следующей ссылке: Ссылка доступна для зарегистрированных пользователей)

Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)

Комментарии / обсуждение (55):

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

Добрый день!
После уничтожения объекта типа Запрос в коде 1С – платформа закрывает курсор и СУБД самостоятельно зачищает TempDB, если считает нужным. Но так-же если запрос создает несколько временных таблиц содержащих значительное количество строк, причём для финальной выборки они уже не нужны – можно их явным образом удалить, даже конструктор запроса знает про это. А вот принудительной очистки TempDB не требует (кроме возможно каких-то аварийных ситуаций).

Добрый день. Подскажите, пожалуйста, как будет правильно:
Нужно сделать запросом выборку, которая будет использоваться несколько раз. Например, она будет служить левой таблицей для других таблиц. Я могу 1) Сформировать ВТ с этой выгрузкой и через МенеджерВТ подгружать ее в запросы. Нужно будет каждый раз создавать описание ВТ, и в какой-то момент я могу попутать тип данных в колонке (кстати, нужно ли всегда указывать этот тип)? 2) выгрузить эту выгрузку в таблицу, которую объявлю в разделе переменных и использовать по мере надобности, буду подгружать ее в запросы как параметр? Спасибо

Добрый день!
Не совсем понятно что Вы имеете в виду. Достаточно создать запрос с МенеджеромВременныхТаблиц, например так:
МенеджерВременныхТаблиц = Новый МенеджерВременныхТаблиц;
Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = МенеджерВременныхТаблиц;
И пока этот менеджер будет существовать – все созданные в запросе временные таблицы будут доступны.
Описание… Никаким описанием обычно не пользуюсь, мне достаточно иногда комментариев и всё. Придерживайтесь одних и те-же правил именования – вам самому будет в дальнейшем легче. Если ошибаетесь часто – тщательнее проверяйте код.
По поводу переменных: если это будет переменная модуля – как только управление вернётся в клиентский контекст – переменная будет уничтожена (при следующем обращении к серверу создана заново но ее значение будет Неопределено), использовать реквизит объекта или реквизит формы в качестве экземпляра Менеджера временных таблиц вам не позволит платформа. Поэтому предпочтительнее за 1 вызов получить все требуемые данные с сервера сразу. Выше описано поведение актуальной платформы без режима совместимости в режиме управляемого приложения.
Если на какой-то вопрос не ответил – пожалуйста уточните.

Здравствуйте.
Подскажите, в чем может быть причина. При работе с отладчиком в какой-то момент появилась ошибка:
Временная таблица уже существует “ИмяВТ”. При этом запрос не изменялся.

Опишите ситуацию поподробнее, пока не очень понятно как это воспроизводится. Что именно вы делаете?

Здравствуйте.
А могли бы вы привести пример, когда индексирование действительно нужно?

Скажем так индексирование временных таблиц это точно не “серебряная пуля” и использовать его имеет смысл только если одновременно:
1.временная таблица большая или очень большая.
2.время выполнения запроса неудовлетворительно велико и есть необходимость его сократить.
Это необходимые условия, но не достаточные (достаточных пока никому не удалось сформулировать) т.е. в любом случае следует делать замеры на выполнение запроса/запросов с использованием индекса и без него.
Если эта временная таблица используется несколько раз (в одном запросе или в нескольких (через МенеджерВременныхТаблиц)) по одинаковому условию соединения шансы на выигрыш по скорости серьёзно возрастают.

Здравствуйте!
У Вас на картинке с подписью “Посмотрим, что изменится, если добавить индекс в таблицу ВТ_Числа” иллюстрация к git-flow

Доброго дня, Евгений!
Спасибо, исправили.

при анализе ТЖ заметил что строка МенеджерВременныхТаблиц.Закрыть() выполняется 692738, т.е. 692 секунды.
сами запросы еще не раскопал, но в любом случае странно что удаление таблиц через Truncate может занимать столько времени
или при закрытии еще на что-то может уходить время?

и дополнительно хотел уточнить
в ТЖ как я понимаю идет учет в десятитысячных долях секунды
для данного примера это выглядит так 11:44.2406-6927375
аналогичным образом я настраивал и лог ТЖ
gt property=”duration” value=”100000″
а вот тут “http://www.gilev.ru/privacystatement/” у вас написано что duration учитывается в секундах
“query:ge property=»Duration» value=»10000″ — ограничивает минимальную длительность 10 секундами”

1. В ТЖ для 8.2 время указывается в десятитысячных долях секунды, а в ТЖ для 8.3 в миллионных долях секунды. Если у вас 8.3, то удаление идет 6,9 сек.
2. Удаление ВТ может работать долго если ВТ очень большая (миллионы записей) или если диски сильно загружены (надо смотреть логи PerfMon).
3. Видимо ошибка в статье, 10000 это будет 1 секунда, а не 10.

ну там явно не миллионы записей, ну может пара сотен тысяч
диски флэшовые, очень хорошие
мне вот кажется что в замер попадает не только усечение временных таблиц, а вообще выполнение всех запросов объекта “Запрос” :))
потому что время примерно совпадает с длительностью всего этапа получения данных с сервера (по данным внутренней статистики, скажем так, ключевых операций)
в общем готовлю базу для замеров

в итоге замер показал проблемы совсем в другом месте

Хорошо что получилось разобраться самостоятельно.

Надо просто сравнить замеры 1С с замерами в профайлере, тогда все станет понятно.

удивила странность в ТЖ

Андрей, добрый день! Спасибо большое за статью, очень полезно и информативно. У меня вопрос, произвели переход на 8.3.,теперь при попытке открыть проводки документа (Дт/Кт) регистра бухгалтерии возникает ошибка “Попытка вставки неуникального значения в уникальный индекс: Microsoft SQL Server Native Client 10/0: Не удается вставить повторяющуюся строку ключа в объект «dbo.#tt35» с уникальным индексом «idx35»”. Я так понимаю что проблема со временной таблицей. Но вот вопрос, что делать дальше. Как можно исправить ситуацию? Можете дать рекомендацию.

Сходу, без анализа ситуации могу предложить попробовать следующие варианты:
– Поставить режим совместимости с 8.2
– Сделать ТиИ
– Сделать выгрузку в DT файл и загрузку из него

Если это не поможет тогда уже надо будет шаманить на месте

Добрый день, Андрей! Очень полезная информация. Глобальный вопрос в том, что лучше для манипуляций с данными использовать Менеджер временных таблиц и через язык запросов проводить модификацию таблицы или лучше все же выгружать в ТЗ и старым добрым способом работать операторами найти и менять значения в Таблице, удалять и добавлять строки и колонки=)?
В качестве конкретного вопроса. Что более быстрее и оптимальнее будет отрабатываться:
1. Оператор “Найти” по таблице значений
2. Отбор по виртуальной таблице через оператор “Где” Набор данных порядка 1 млн. строк

Правильный ответ: провести опыт и посмотреть на вашем сервере и ваших данных.

подскажите пожалуйста как в 83 можно кэшировать мвт между серверными вызовами? в 82 можно было его положить в хранилище значений, а отныне больше нет…

Добрый день! Подскажите, если я помещаю во временную таблицу данные, которые изначально индексированы, то эти поля во временной уже не индексированы?
Допустим, запрос:

выбрать Т.Ссылка, Т.Контрагент, Т.Подразделение
Поместить ВТ
ИЗ Документ.ПоступлениеТоваровУслуг КАК Т;

Ссылка ведь всегда индексирована, и если дальше в запросе мы по этой ссылке будем соединять эту таблицу с другой по ссылке, то имеет смысл заново индексировать поле Ссылка (при большом количестве записей)? (про чтение данных из документов, а не из регистров сейчас речи не идет).

> если я помещаю во временную таблицу данные, которые изначально индексированы, то эти поля во временной уже не индексированы?

Да, во временной таблице индекса по этим полям уже не будет.

> имеет смысл заново индексировать поле Ссылка (при большом количестве записей)?

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

Андрей, спасибо за ваш труд. Курс по оптимизации мне очень понравился, хорошо структурирован, все по делу и без воды. За статьи и обратную связь отдельное спасибо!

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

Кажется у вас опечатка или ошибка… ))
>Как только пакетный запрос завершается, неявный МВТ закрывается, и >автоматически последует команда «Truncate table», которая удаляет >созданную таблицу.

Скорее всего имелось в виду Drop table.

Truncate table – Удаляет все строки в таблице, не записывая в журнал удаление отдельных строк.

А я думал заметит ли кто – нибудь 🙂
Да, 1С всегда используется Truncate вместо Drop, что бы по возможности не создавать новую таблицу со такой же структурой, а использовать уже существующую, но принципиально сути это не меняет.

не в тему – прочитал и опять нахлынуло, имхо, как хотелось бы, чтобы действительно толковые головы разработчиков платформы 1С приложили усилия к продвижению по пути (в целом очень сложному пути) к избавлению от этих временных таблиц при написании запросов вместо создания сомнительной полезности управляемых форм и тем более Такси

Уже пора рубрику открывать “Осторожно! Гилев!” или “Киноляпы Гилева” (это про видеоуроки).

Похоже к нам заглянули старожилы Мисты ))
Ok, но здесь не получится развести традиционный флуд 😉

Вообще без конкретики с Вашей стороны сложно на это что-то ответить.

И непонятно, как этот комментарий вообще относится к временным таблицам.

Не понял. Вы серьезно говорите, что если используется явно МВТ, то создаются глобальные таблицы. Но глобальные таблицы существуют до тех пор пока не завершаться все сеансы (ВСЕ, а не только тот spid, который ее создал). То есть выход из процедура или функции (неявное закрытие МВТ), я уже молчу о сбоях, не приведут к уничтожению глобальной таблицы.
2) Если таблица глобальная, то она будет доступна всем сеансам, то есть если 2 пользователя выполняют одинаковую процедуру, то они будут мешать друг другу, то есть они не смогут параллельно их создавать, то есть возникнет проблема изоляции.

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

1) глобальные таблицы существуют до тех пор пока не завершаться все сеансы (ВСЕ, а не только тот spid, который ее создал)
—
Вы не правы, в контексте 1С глобальная таблица уничтожается в любом из трех перечисленных в статье случаев. Можете самостоятельно проверить в Profiler. При штатном завершении программы, никаких сбоев при работы временных таблиц не будет.

2) Если таблица глобальная, то она будет доступна всем сеансам, то есть если 2 пользователя выполняют одинаковую процедуру, то они будут мешать друг другу, то есть они не смогут параллельно их создавать, то есть возникнет проблема изоляции.
—
Вы снова ошибаетесь.
СУБД присваивает уникальные служебные имена временным таблицам, выглядят они примерно так «##tt1_____________________________________________000000000087».
Таким образом 1С сеанс никак не сможет прочитать данные временной таблицы другого сеанса. Более того, если бы то о чем вы говорите было бы возможно, то 1С вообще бы не смогла нормально работать в многопользовательском режиме.

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

“Сейчас же многие разработчики слепо следуют рекомендации, не отслеживая при этом используется ли вообще созданный ими индекс, а если да, то приносит ли он желаемый эффект.”
Сорри за некропостинг, но я прямо себя вспомнил некоторое время назад, когда сдал спеца по платформе и гордо везде совал индексы. И очень увидился, увидев, что запрос БЕЗ индексов (в моем случае) стал работал в два раза быстрее 🙂

Да, к сожалению такое бывает чаще чем хотелось бы.

Провел эксперимент с индексированием временной таблицы на SQL Server 2012. Как и ожидалось, с индексом выборка работает существенно быстрее, чем без: примерно 1 миллисекунда против 80. По статистике чтений все также в пользу индекса. Не совсем понятно, почему у вас получился такой результат.

Вот поэтому я и говорю что нужно смотреть в каждом конкретном случае.
Поставил SQL Server 2014, платформа 8.3, результат такой же как в статье, запрос без индекса все равно работает быстрее чем с индексом.

ещё бы, именно MS SQL 2014 представлялся публике, как отличный инструмент “инмемори”-оптимизации. На других серверах и версиях верно “нужно смотреть в каждом конкретном случае”.

Дело здесь не в In-Memory OLTP, временная таблица и так была в памяти. Просто именно на моем компьютере данный запрос работает быстрее со сканированием, на другом компьютере с другой версией СУБД возможна другая ситуация.

Быстрее работает выборка (ВЫБРАТЬ ВТ_Числа.Число ИЗ ВТ_Числа КАК ВТ_Числа ГДЕ ВТ_Числа.Число = 777) или вставка + выборка?

На 2014 и 8.3 быстрее именно вставка в таблицу без индекса, сама выборка без индекса медленнее, но в итоге затраты на создание индекса так велики, что для данного запроса получается выгоднее его не создавать.

это ок, меня смутило что у вас select с индексом медленнее отработал.

В момент написания статьи использовалась платформа 8.2 и SQL Server 2008 R2, там селект действительно работал медленнее.

Хорошая статья, но по пункту “Надо ли индексировать временные таблицы?” – типовая рекомендация правильная, и лучше указывать вместо “Используйте индексирование только в том случае, если вы видите от этого явный положительный эффект.” формулировку “Используйте нужно индексировать поля условий и соединений во временных таблицах во всех случаях, кроме тех где нет явного положительного эффекта.”

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

Также не указан пример при соединении двух таблиц значительного объема.

Для себя я сделал вывод, что:
– индексирование по полям поиска не следует делать, если поиск по таблице выполняется 1-3 раза, тогда table scan без создания индекса сработает быстрее
– индексирование по условиям соединения не следует делать, если соединяемая таблица содержит НЕ БОЛЕЕ трех записей, тогда nested loop также отработает быстрее.

>по пункту «Надо ли индексировать временные таблицы?» — типовая рекомендация правильная, и лучше указывать вместо «Используйте индексирование только в том случае, если вы видите от этого явный положительный эффект.» формулировку «нужно индексировать поля условий и соединений во временных таблицах во всех случаях, кроме тех где нет явного положительного эффекта.»

Типовая рекомендация говорит, что поля условий и соединений нужно индексировать ВСЕГДА и никаких если.

>«нужно индексировать поля условий и соединений во временных таблицах во всех случаях, кроме тех где нет явного положительного эффекта.»

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

>Кроме того Вы привели частный пример, где создается одна таблица и производится выборка по одному полю, но если бы Вы привели пример запроса, где данные из первой таблицы выбираются не единожды, то результат был бы совершенно другой (вспомните хотя бы многоэтажные запросы ЗУПа).
Также не указан пример при соединении двух таблиц значительного объема.

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

>индексирование по полям поиска не следует делать, если поиск по таблице выполняется 1-3 раза, тогда table scan без создания индекса сработает быстрее

Всегда зависит от конкретной ситуации

>индексирование по условиям соединения не следует делать, если соединяемая таблица содержит НЕ БОЛЕЕ трех записей, тогда nested loop также отработает быстрее.

Если в таблице 3 строки, нет абсолютно никакого смысла ее индексировать, ни поля соединений ни условий. Nested Loops с поиском по индексу никак не связан, при возможности Nested Loops может использовать индекс для поиска.

Источник