Имеется два запроса. Первый выполняется вдвое дольше чем второй. Почему?
Первый
    "ВЫБРАТЬ
    |    МойДокумент.Ссылка КАК Ссылка,
    |    МойДокумент.ВерсияДанных КАК Версия
    |ИЗ
    |    Документ.МойДокумент КАК МойДокумент"

Второй
    "ВЫБРАТЬ
    |    МойДокумент.Ссылка КАК Ссылка,
    |    МойДокумент.ВерсияДанных КАК Версия
    |ПОМЕСТИТЬ МойДокументВременная
    |ИЗ
    |    Документ.МойДокумент КАК МойДокумент
    |;
    |
    |/////////////////////////////////////////////////////////////
    |ВЫБРАТЬ
    |    МойДокумент.Ссылка
    |ИЗ
    |    МойДокументВременная КАК МойДокумент"

При этом если сделать вот так то первый запрос выполняется быстрее второго.
Первый
    "ВЫБРАТЬ
    |    МойДокумент.Ссылка КАК Ссылка
    |ИЗ
    |    Документ.МойДокумент КАК МойДокумент"

Второй
    "ВЫБРАТЬ
    |    МойДокумент.Ссылка КАК Ссылка
    |ПОМЕСТИТЬ МойДокументВременная
    |ИЗ
    |    Документ.МойДокумент КАК МойДокумент
    |;
    |
    |/////////////////////////////////////////////////////////////

    |ВЫБРАТЬ
    |    МойДокумент.Ссылка
    |ИЗ
    |    МойДокументВременная КАК МойДокумент"

ну так временную таблицу еще создать надо

кэширование

(3) Кэширование чего? Результат одинаков независимо от порядка выполнения запросов.

Второй небось выполняется сразу после первого без перезагрузки скл?

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

(4) перезагрузите компьютеры. После этого запускайте второй запрос, а за ним первый.

(0) Потому что таблица документа физически может находиться в разных таблицах и для её выборки создаются подзапросы, ВТ помещается в одну

(5) Нет. Оно проверялось неоднократно с разным набором полей. Короткий запрос выполняется вторым для чистоты эксперимента.

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

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

(11) То есть один и то же набор данных для временной таблицы отбирается быстрее чем просто так?

(12) Во втором случае все таблицы по очереди складываются в ВТ, а в первом - вложенные запросы.
Ну и (11), да

а так какой результат?
"ВЫБРАТЬ
    |    МойДокумент.Ссылка КАК Ссылка,
    |    МойДокумент.ВерсияДанных КАК Версия
    |ПОМЕСТИТЬ МойДокументВременная
    |ИЗ
    |    Документ.МойДокумент КАК МойДокумент
    |;
    |
    |/////////////////////////////////////////////////////////////

    |ВЫБРАТЬ
    |    МойДокумент.Ссылка,
    |    МойДокумент.Версия
    |ИЗ
    |    МойДокументВременная КАК МойДокумент"

(11) > ВерсияДанных - сама по себе таблица, а не поле
это откуда инфа?

(12) в данном "неявном" случае соединения - да.
ВТ всегда выигрывает против неявного соединения.
Другое дело, что ВерсияДанных никогда в 1С не была ПОЛЕМ, а отдельной хрень-таблицей....

(0)есть вещь такая, называется книга! не мешало бы ее почитать)))

(15) да тут на мисте, в славные времена "от двадцатитысячников" как-то обсуждалось.

(18) ты сам так считаешь, что версия это таблица?

(19) Лешу я записал в свой список, можно не продолжать эту тему.

Леша, лучше молчи, за умного сойдешь

Автор неправильно меряет и, возможно, скоро мы выясним забавные подробности.

(14) Обратный. С виртуальной таблицей выполняется процентов на 10 быстрее чем без нее.

(17) И какую книгу ты можешь порекомендовать для чтения по этому поводу?

(0)+ Кстати это не только с версией данных. Если обычных реквизитов документа штук пять вместо версии данных отобрать, то эффект похожий только менее явно выражен.

(22) Не исключаю.

(20) огласите весь список (с)

(24) а как ты меряешь?

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

(28) тут до клиента еще проблемы.
Это общая неоптимизнутость в связке 1С - СУБД.

(29) Ты сравнивал производительность в profiler и в замере производительности?

(27) Отладка > Замер производительности. И кручу оба запроса в цикле по 10 раз. Потом смотрю циферки.

(29) Ты не поверишь, в самом sql, такая же фигня. Иногда достаточно выбросить из запроса 1 поле для существенного ускорения запроса. Запрос выполняется непосредственно в менеджмент - студии, то есть инструментальными средствами самой СУБД.

(30) Нет. :(

(32) "Иногда достаточно выбросить из запроса 1 поле для существенного ускорения запроса"

Держите indexSeek вместо indexseek+keylookup или даже tablescan/indexscan

(31) Вот ты и попался.

(31) Бери 100500 строчную таблицу и делай по одному запросу каждого вида, перезагружая sql (и сервер 1С) перед каждым запросом.

(36) Это будет проблематично. Пользователи расстроятся. :( А в чем именно я облажался? Думаешь кэширование?

(37) Знаю, что кэширование.
Хотя, это не отменяет твоего парадокса в (0)

Парадокс может быть объяснен RLS кстати

(34) Я как бы немного о другом пытался сказать. Имелось ввиду то, что количество полей в результирующем запросе влияет на время выполнения запроса. Особенно ярко этот эффект проявляется если в перечень полей добавлять/удалять поля из присоединенной таблицы. Если таблицы большие, то не надо ничего перезагружать даже, все видно невооруженным глазом.

(39) Кстати да.

(40) Тоже самое можно сказать про поля класса image и nvarchar

(39) Не отменяет. А причем тут РЛС? Полные права же.

(31) Некорректное сравнение. Чтобы оценить и сравнить производительность тебе нужно выполнить след. действия:

1) Выполнить первый запрос. Зафиксировать информацию о его длительности имеющимися средствами.

2) В management studio выполнить запрос:

DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE

3) Выполнить второй запрос. Зафиксировать информацию о его длительности имеющимися средствами. Сравнить результаты замеров производительности запросов.

ps. Такие замеры производить только на тестовых серверах (в крайнем случае на продакшн, но после завершения/до начала "рабочего дня").

(32)" Ты не поверишь, в самом sql, такая же фигня"
вообще, мы тут работаем с одноэсовыми данными, а не нормализованными, поэтому даже в SQL неявное соединение (развернутое в запросе SQL) - будет тормознее.