3 главных вопроса про временные таблицы 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.1 секунда и еще 0.1 секунда на сканирование всей таблицы, чтобы вернуть нам 1 строку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. в запросе использована команда УНИЧТОЖИТЬ
  2. вызван метод МенеджерВременныхТаблиц.Закрыть()
  3. объект МенеджерВременныхТаблиц перестал существовать, например, завершилась работа процедуры/функции, которая породила этот объект, или пользователь закрыл программу

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

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

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

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

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

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

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

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

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

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

dbcc shrinkfile (tempdev, ЖелаемыйРазмерФайлаДанныхМб)
dbcc shrinkfile (templog, ЖелаемыйРазмерФайлаЛоговМб)

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

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

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

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

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

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

Заключение

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

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

Чтобы узнать о всех способах и методах оптимизации систем на платформе 1С, рекомендую пройти курс:
Ускорение и оптимизация систем на 1С:Предприятие 8.3. Подготовка на 1С:Эксперт по технологическим вопросам

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

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

Мы ведем группу ВКонтакте – http://vk.com/kursypo1c.

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


Статья по программированию - в PDF-формате

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

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

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

Если Вы уже участник группы – нужно просто повторно авторизоваться в ВКонтакте, чтобы скрипт Вас узнал. В случае проблем решение стандартное: очистить кеш браузера или подписаться через другой браузер.

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

  1. MDaryaA сказал:

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

    • Escander сказал:

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

  2. Евгений Пузиков сказал:

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

  3. unvis сказал:

    при анализе ТЖ заметил что строка МенеджерВременныхТаблиц.Закрыть() выполняется 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.

      • unvis сказал:

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

  4. Нат сказал:

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

    • Андрей Бурмистров сказал:

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

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

  5. ba-lab сказал:

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

    • Андрей Бурмистров сказал:

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

  6. Артем Сагателян сказал:

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

    • Андрей Бурмистров сказал:

      Попробуйте использовать временное хранилище
      ПоместитьВоВременноеХранилище(< Данные>, < Адрес>)
      ПолучитьИзВременногоХранилища(< Адрес>)

  7. Stark сказал:

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

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

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

    • Андрей Бурмистров сказал:

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

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

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

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

  8. regmy сказал:

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

    • Андрей Бурмистров сказал:

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

  9. Юрий сказал:

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

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

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

    • Андрей Бурмистров сказал:

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

  10. vladak сказал:

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

  11. asd сказал:

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

    • Евгений Гилев (Мастер-тренер) сказал:

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

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

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

  12. Struk сказал:

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

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

    • Андрей Бурмистров сказал:

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

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

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

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

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

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

      • GolD сказал:

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

  13. Mike сказал:

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

    • Андрей Бурмистров сказал:

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

      • andr_andrey сказал:

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

        • Андрей Бурмистров сказал:

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

      • Mike сказал:

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

        • Андрей Бурмистров сказал:

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

            • Андрей Бурмистров сказал:

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

  14. georgich88 сказал:

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

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

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

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

    • Андрей Бурмистров сказал:

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

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

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

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

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

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

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

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

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

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

    • Андрей Бурмистров сказал:

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

      • Rurai сказал:

        Андрей, вы представляете вчерашнего студента, который сдал на Эксперта и понял, что он “Великий Процессор”, с этого времени?
        И всем своим подчиненным он дает задание, делать так, как на Великом Экзамене от 1С..
        И не важно, что всё работать начинает всё хуже, и хуже.

        Важно, что по правилам от 1С..Платформа которой содержит ошибки, не исправленные годами..

        Кстати, в комментариях есть подобный пример.

        Еще одно кстати ), если вы автор курса, мне нравится как он преподносится. Был курс по мобильной платформе, там было очень много “воды”. Здесь всё хорошо сжато.
        Неплохо)

        • Евгений Гилев (Мастер-тренер) сказал:

          Руслан, Вы описывают гипертрофированного специалиста, ярого фаната 1С, который готов в кулачном бое доказать SAP’еру, что 1С круче :))

          Конечно, такие “спецы” бывают, но их не очень много.

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

          Поэтому, свежеиспеченного 1С:Специалиста нельзя сразу бросать в одиночку на важные проекты.

          Полученные знания еще должны быть обработаны напильником реальных внедрений.

          P.S.
          Да, Андрей автор курса
          Этот курс разрабатывался около года, поэтому считаем, что он получился высокого качества.

  15. Ирина сказал:

    Огромное спасибо!!! я очень редко применяю временные таблицы, хотя работала в Российской компании (я из Казахстана), так вот руководитель программистов ну прямо таки настаивала, чтобы было больше временных таблиц и переубедить её было невозможно!!! :) ну, а потом…. было очень сильно удивлялась… почему это так долго работает запрос!!! :)
    Ещё раз спасибо за статью….

    • Андрей Бурмистров сказал:

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

  16. Игорь Сапрыгин сказал:

    dbcc shrinkfile (tempdev, ЖелаемыйРазмерФайлаДанныхМб)
    dbcc shrinkfile (templog, ЖелаемыйРазмерФайлаЛоговМб)
    Возникает вопрос – а какой размер файла данных мне можно пожелать? :) Чем меньше – тем лучше? Есть же какой-то объем, ниже которого файл просто не сожмется? Есть ли смысл сжимать не до минимального размера?

    • Андрей Бурмистров сказал:

      Пожелать можно любой размер, даже если вы укажите 1Мб, файл все равно будет сжать только на столько, на сколько это возможно.
      Размер можно вообще не указывать, это не обязательный параметр, в этом случае будет использован размер по умолчанию. Размер по умолчанию это тот размер с которым файл создавался изначально.
      Слишком сильно и часто сжимать файлы смысла нет, это и не нужно.

      Подробнее про данную команду можно почитать здесь: https://msdn.microsoft.com/ru-ru/library/ms189493.aspx

  17. EvgeniuXP сказал:

    Спасибо – полезно – это еще раз подтверждает, что человеку дана голова не только шапку носить :)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Мы используем файлы cookies, чтобы сделать сайт удобнее.
Продолжая просмотр сайта, Вы соглашаетесь с их использованием.
Подробнее