Как пользоваться таблицей в 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 строку.