День добрый.
Понял, что заблуждался.
Строка кода
Артикул=Номенклатура.Артикул (1);

создает объектный кэш.
Кэш живет 20 МИНУТ (как оказалось), но через 20 секунд проверяется на валидность считывание поля _version из базы.
http://langslab.com/ebooks/prof-dev2/tome1/pr-dev-t1-ch04

Все нормально, все логично, пока.

Заходим в профайлер и видим, что если мы выполним код (1) ранее чем за 20 секунд - ничего не произойдет, а если после 20 секунд - выполниться 2! запроса:

Первый запрос:

exec sp_executesql N'SELECT
T1._Version
FROM _Reference152 T1
WHERE T1._IDRRef = P1',N'P1 varbinary(16)',0x8041A8E513C95CF74D0C57393F6E2FDB


Второй запрос:

exec sp_executesql N'SELECT
T2._IDRRef,
T2._Version,
T2._Marked,
T2._IsMetadata,
T2._ParentIDRRef,
T2._Folder,
T2._Code,
T2._Description,
T2._Fld2303,
T2._Fld2304RRef,
T2._Fld2305,
T2._Fld2306,
T2._Fld2307,
T2._Fld2308,
T2._Fld2309,
T2._Fld2310,
T2._Fld2311,
T2._Fld2312RRef,
T2._Fld2313RRef,
T2._Fld2314RRef,
T2._Fld2315RRef,
T2._Fld2316,
T2._Fld2317,
T2._Fld2318RRef,
T2._Fld2319,
T2._Fld2320RRef,
T2._Fld2321RRef,
T2._Fld2322RRef,
T2._Fld2323RRef,
T2._Fld2324RRef,
T2._Fld2325RRef,
T2._Fld2326RRef,
T2._Fld2327RRef,
T2._Fld2328RRef,
T2._Fld2329,
T2._Fld2330,
T2._Fld2331,
T2._Fld2332,
T2._Fld2333,
T2._Fld2334RRef,
T2._Fld2335RRef,
T2._Fld2336RRef,
T2._Fld2337RRef,
T2._Fld2339,
T2._Fld2340,
T2._Fld2341RRef,
T2._Fld2342RRef,
T2._Fld2343RRef,
T2._Fld2344RRef,
T2._Fld2345_TYPE,
T2._Fld2345_RTRef,
T2._Fld2345_RRRef,
T2._Fld2346_TYPE,
T2._Fld2346_RTRef,
T2._Fld2346_RRRef,
T2._Fld2347,
T2._Fld2348,
T2._Fld2349,
T2._Fld2350,
T2._Fld2351RRef,
T2._Fld2352RRef,
T2._Fld2353RRef,
T2._Fld2354_TYPE,
T2._Fld2354_S,
T2._Fld2354_RRRef,
T2._Fld2355RRef,
T2._Fld2356RRef,
T2._Fld2357,
T2._Fld2338,
T2._Fld2358RRef,
T2._Fld2359RRef,
T2._Fld2360RRef,
T2._Fld24140RRef,
T2._Fld24141_TYPE,
T2._Fld24141_RTRef,
T2._Fld24141_RRRef,
T2._Fld27221,
T2._Fld27222,
0 AS SDBL_IDENTITY
FROM _Reference152 T2
WHERE T2._IDRRef = P1 AND T2._Version <> @P2',N'P1 varbinary(16),@P2 varbinary(8)',0x8041A8E513C95CF74D0C57393F6E2FDB,0x0000000000E96026


И вот тут то начинаются загадки...

(118) Ты нихера не ответил.

(120) вы просто не хотите читать.
А хотите верить и дальше, что 1С - великая сситема.
А не набор поделок на коленке.
Вы хотите получить ответ, совмещающий как реализацию кэша (как области хранения и быстрой выборки часто используемых данных), так и прямо противоположные этому результаты работы 1С-севрера (и данные профайлера), которые видите перед собой.
А так НИКОГДА НЕ ПОЛУЧИТСЯ.
Нужно чем-то поступиться - либо определение кэша сместить в "понятия 1С", либо - признать, что ошибался всю сознательную деятельность работы с 1С :)))

(121) Иди, убей себя ап стену, балаболка.

(114)>>значит данные не хранятся в кэше и они запрашиваются постоянно в базульку
- именно это и подтверждается всеми данными, в том числе - выкладками    H A D G E H O G s.
Но очень трудно признаться себе в том, что тебя нагло и беспринципнро обманывали долгое время, а ты еще и радовался этому :)

(122) это ты балаболка.
бестолковая :)

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

(122) вижу, ты уже убился.. бедняжка..
стена-то хоть не пострадала? :)

(111)>>А если версия не изменилась?
- уже написано:
"Версия не изменилась - берет снова из кэша данные (и так в течении 20 минут)."
т.е. УЖЕ после того, как получены данные (второй запрос), сравнены версии, и выявлено, что версия не менялась.
"...потом - дает прирост, только если получение данных 1С-сервером из "своего" кэша быстрее, чем заново считанных."
Вы просто не хотите (или уже не умеете? ;) ) читать.

+( 127) т.е., грубо говоря, данные кэша - хранятся в одной области памяти (диске), данные вновь полученной выборки для валидации (второй запрос) - в другой области.
И если 1С серверу "удобнее" и быстрее получить эти данные из "области" кэша - то прирост будет.
Если нет - прироста не будет.
ЧТо и подтверждено многочисленными практическими наблюдениями (прироста нет после 20 сек, т.к. обе "области" - примерно "равнодоступные" для сервера по быстродействию железа)

(128) Все, иди лесом, дятелъ.

++ это и есть "понимание кэша" по 1С, если кто еще не понял :)

(129) лесом уже ты пошел.
С поста так 10-го :)
И чем дальше - тем больше дров наломал.

>>Все, иди лесом, дятелъ.
- чем бы 1сник не тешился - лишь бы не терял веры в 1С! :)
ну, и перейти на ругань - первейшее дело для 1сника.

(128) Чтобы ты немножко задумался зайчатками своего мозга - размер выборки второго запроса =0.

Ребята, давайте жить дружно!

А про быструю и медленную часть сервера 1С - порадовало. Давненько такого не было.

(136)>>А про быструю и медленную часть сервера 1С - порадовало
ну, а что еще тебя может порадовать - не поиск же ответа :)
Так, одна радость - себя показать, других посмотреть. Авось кто приметит....

(135) ты "одинаково дружно" не дружишь даже сам с собой :)

(137) Конечно есть, если судить по (128):

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


А если выполнить запрос в (0) - нет.

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

Я провел такой замер кодом

Сообщить(ТекущаяДата());
Количество = 1000;
ИмяСправочникаБезГрупп = Метаданные.Справочники.СвойстваМетаданных2iS.Имя;
ИмяПоля = "ПометкаУдаления";
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ " + XMLСтрока(Количество) + "
|    Т.Ссылка
|ИЗ
|    Справочник." + ИмяСправочникаБезГрупп + " КАК Т";
МассивСсылок = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("Ссылка"); //Готовим массив ссылок
Количество = МассивСсылок.Количество();
Сообщить("Размер выборки " + Количество);
УФ(сНачатьЗамер, Количество, "Подготовка объектного кэша");
Для Каждого Элемент ИЗ МассивСсылок Цикл
   Пустышка = Элемент[ИмяПоля];
КонецЦикла;
УФ(сЗакончитьЗамер);

УФ(сНачатьЗамер, Количество, "Чтение с использованием объектного кэширования");
Для Каждого Элемент ИЗ МассивСсылок Цикл
   Пустышка = Элемент[ИмяПоля];
КонецЦикла;
УФ(сЗакончитьЗамер);

УФ(сНачатьЗамер, Количество, "Чтение отдельными запросами");
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
|    Т.Ссылка,
|    Т." + ИмяПоля + "
|ИЗ
|    Справочник." + ИмяСправочникаБезГрупп + " КАК Т
|ГДЕ
|    Т.Ссылка = &Ссылка";
Для Каждого Элемент ИЗ МассивСсылок Цикл
   Запрос.УстановитьПараметр("Ссылка", Элемент);
   Пустыщка = Запрос.Выполнить().Выгрузить()[0][ИмяПоля];
КонецЦикла;
УФ(сЗакончитьЗамер);

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
|    Т.Ссылка,
|    Т." + ИмяПоля + "
|ИЗ
|    Справочник." + ИмяСправочникаБезГрупп + " КАК Т
|ГДЕ
|    Т.Ссылка В(&МассивСсылок)";
Запрос.УстановитьПараметр("МассивСсылок", МассивСсылок);
УФ(сНачатьЗамер, Количество, "Чтение общим запросом");
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
   Пустыщка = Выборка[ИмяПоля];
КонецЦикла;
УФ(сЗакончитьЗамер);

И получил ожидаемый результат

Окончание замера "Подготовка объектного кэша" - Длительность = 8,144 с, Среднее = 0,008144 с
Окончание замера "Чтение с использованием объектного кэширования" - Длительность =  0с, Среднее =  0с
Окончание замера "Чтение отдельными запросами" - Длительность = 2,106 с, Среднее = 0,002106 с
Окончание замера "Чтение общим запросом" - Длительность = 0,078 с, Среднее = 0,000078 с

(141) Вообще то есть транзакционный кэш. Практика грязного чтения весьма порочна.

Замени

МассивСсылок = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("Ссылка"); //Готовим массив ссылок

на

МассивСсылок = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("Ссылка"); //Готовим массив ссылок

СходитьПокуритьВСекундах(22);

(143) Цитирую себя же из (141) "- общая длительность теста для упрощения условия не должна превышать 20 сек "
В предлагаемом варианте объектный кэш будет целиком перепроверен (количество обращений к серверу по идее будет таким же, как и при его заполнении).

Вот результаты

Окончание замера "Подготовка объектного кэша" - Длительность = 8.018 с, Среднее = 0.008018 с
Окончание замера "Чтение с использованием объектного кэширования до 20сек" - Длительность = 0.016 с, Среднее = 0.000016 с
Окончание замера "Чтение с использованием объектного кэширования после 20сек" - Длительность = 7.441 с, Среднее = 0.007441 с
Окончание замера "Чтение отдельными запросами" - Длительность = 2.215 с, Среднее = 0.002215 с
Окончание замера "Чтение общим запросом" - Длительность = 0.078 с, Среднее = 0.000078 с

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

(144) "лишь немногим быстрее чтения объекта в кэш."

Почти уверен, что справочник содержит ТЧ.

Если ТЧ не будет - разрыв будет существенней.

(145) Да, справочник был с ТЧ.
А вот почти та же картина на справочнике без ТЧ

Окончание замера "Подготовка объектного кэша" - Длительность = 6.988 с, Среднее = 0.006988 с
Окончание замера "Чтение с использованием объектного кэширования до 20сек" - Длительность = 0.016 с, Среднее = 0.000016 с
Окончание замера "Чтение с использованием объектного кэширования после 20сек" - Длительность = 6.77 с, Среднее = 0.00677 с
Окончание замера "Чтение отдельными запросами" - Длительность = 2.34 с, Среднее = 0.00234 с
Окончание замера "Чтение общим запросом" - Длительность = 0.078 с, Среднее = 0.000078 с

Воопщем, мне все понятно. Что ничего не понятно, зачем они так сделали.

И почему после 20 секунд выполняется попытка тащить с SQL обновленных данных, даже если их нет. А их нет, так как версия не изменилась. Но на innerjoin с ТЧ надо потратиться время.

А разница в 8.018сек- 7.441 с возникает из-за того, что
при 8.018сек - выборка не пуста, а при 7.441 - пуста.

(147) Значит я был не прав насчет InnerJoin

(147) Добавь время запроа на выборку несуществющих элементов. Например список кодов которых нет в базе. Тогда посмотрим сколько времения занимает второй запрос

(150) А это зачем?

Думаю чтение версии отдельно и всего объекта выполняются вместе, чтобы не делать новый запрос к серверу СУБД в случае если версия изменилась.

Предполагаю что алгоритм примерно такой, если прошло 20 сек
1. Строим запрос для чтения версии
2. Строим запрос для чтения объекта
3. Склеиваем 1+2 в пакет
4. Отправляем запрос в СУБД
5. Получаем результат пакета из СУБД
6. Если версия из результата запроса 1 не совпадает с версией в кэше, то берем результат запроса 2 и помещаем (обновляем) его в кэш.
7. Возвращаем объект из кэша.

Вернее не код а любой атрибут без индекса
эмуляция
Select * From T2
WHERE T2._IDRRef = P1 AND T2._Version <> @P2

(152) Но это же дикость!

(153) Понял.

(151) Ну у тебя то в итоге получается 2 запроса.
вот Чтение отдельными запросами это тогда когда запись изменена.

(156) И тогда, когда не изменена - тоже 2 запроса.

(154) Алгоритм в 152 я предложил, основываясь на твоих наблюдениях в (0). Сам пока не проверял. Возможно ты провел не очень чистый эксперимент. Действительно такой алгоритм кажется неоптимальным, т.к. изменения данных происходят гораздо реже, чем чтение.

(157) Я про то , что тест тянет все записи, а в реалии они не тянутся

Кста ответь на вопрос из v8: Чудеса с индексами.
что дает условие на равество =4.7 для SQL варианта.
В файловой версии возвращает 5. Там ясно что приведение через cast к Число.
А вот если в SQL вернет 4, то значит индексы хранятся ввиде int и приводятся к ште

(153) WHERE T2._IDRRef = P1 AND T2._Version <> @P2


Все равно делает поиск по кластерному индексу.

(159) 1С зарегало ошибку платформы на партнерском :-)

(160) Это понятно. Но одно дело вернуть данные потом их обработать на сервере или ничего не возвращать.

Надо попробовать 18 релиз поставить, нуавдруг.

(158) Может и поломалось что-то. Как вариант - задать вопрос на партнерском - у кого есть доступ

(162) Вооот! Именно про это я говорил в (148)

может вся бодяга из за обращений клиента к серверу? Типа 1С сразу формирует и то и то, чтобы случ чего 2 раза на сервер не бегать?

(160) Так что SQL то возвращает или как оно и должно ничего не возвращает ?

(167) Оно не должно делать 2 запрос вообще.


Tormozit, будь добр, закинь в тест запрос по 1 полю:

ВерсияДанных

(165) На самом деле не все ясно, так как при подготовке кэша не нужно делать 2 х запросов, так как данных просто нет и нужно делать только один запрос. Просто в 1С могут и при этом сделать 2 запроса.

Надо ставить 18 релиз короче.
Этим я и займусь счаст.

(167) Это я прекрасно понимаю. Достаточно второго.

(168) ничего не изменилось (замер для справочника без ТЧ)

Окончание замера "Подготовка объектного кэша" - Длительность = 7.082 с, Среднее = 0.007082 с
Окончание замера "Чтение с использованием объектного кэширования до 20сек" - Длительность = 0.016 с, Среднее = 0.000016 с
Окончание замера "Чтение с использованием объектного кэширования после 20сек" - Длительность = 6.739 с, Среднее = 0.006739 с
Окончание замера "Чтение отдельными запросами" - Длительность = 2.106 с, Среднее = 0.002106 с
Окончание замера "Чтение общим запросом" - Длительность = 0.094 с, Среднее = 0.000094 с

(168) + Если я правильно понял "закинь в тест запрос по 1 полю:ВерсияДанных", то менял ИмяПоля = "ВерсияДанных".

(171) Достаточно первого запроса, и, если он вернет версию, отличную от хранимой (что очень редко!) - то - 2 запрос.

(171) И тогда у теста в(172), для "Чтение с использованием объектного кэширования до 20сек" время будет не  6.739  секунд, а 2.1 секунды.

8.2.18:

Оптимизировано получение из базы данных прикладных объектов без табличных частей при вызове метода ПолучитьОбъект() и при обращении к свойствам «через точку» от ссылки.

(174) Да. Здравый смысл так говорит. Так что либо грязный эксперимент, либо ошибка платформы.

сам кэш в исполнении 1С хранится где вообще?

(178) Ты не поверишь :-)

(178) На сервере, но в каком именно процессе я точно не знаю.

(176) Ну если она исправление такого косяка назвали оптимизацией, то явно набивают цену)

(180) хотелось бы верить. Просто, исходя из (0), ощущение такое, что он хранится на клиенте.

Вот честно - я за хранение кэша подозреваю не
rphost а rmngr, судя по активности памяти и усиленной работе с файлом snccntx.000001CF.dat

(183) хорош флудить, иди в будвар уже

(180) Посмотри в первые 20 секунд тем же filemon-ом от Руссиновича, что за файлы читаются.
Я заметил только rmngr за чтением snccntx.000001CF.dat

+(182) вернее даже так, смысл этого запроса в том, чтобы сервер Предприятия 1С выполнял обращение непосредственно к серверу БД только 1 раз в любом случае.

(174) А зачем первый? Если второй запрос ничего не вернул, значит запись актуальна.

(184) Ждааать. Ждаааать. © Храброе Сердце.

(176) так ты прочитал что оптимизировано, или же протестил уже?

(187) Или хотя бы так, но так - хуже.
Надо же делать связку со всеми ТЧ. И в 99% случаев - вернется пустой результат.

(181) да походу они забыли про кэш давным давно и он не работал :)

(189) Счаст качается 18

(188) Ответь на 167. Интересно ведь.

(191) Посмотри типовую УПП, как там все через точку херачется. Я конечно думал, что там "хитрый смысл" и сделано специально, полез ковырять - и появилась эта тема.

По идее для таблиц без соединений (с ТЧ) оптимальным будет такой алгоритм, если прошло 20 сек
1. Строим запрос для чтения объекта (возвращает данные объекта, если версия изменилась), т.е. только второй запрос из (0)
4. Отправляем запрос в СУБД
5. Получаем результат из СУБД
6. Если результат не пустой, то помещаем его в кэш объектов.
7. Возвращаем объект из кэша.

(190) Все раввно если запрос вернул, значит запись изменилась и нужно тянуть табличные части. Убиваем 2 х зайцев. Второй запрос к ТЧ не будет тянуть Шапку.

А вот для таблиц с соединениями надо
1. Отправляем в СУБД запрос на получение версии
2. Получаем результат и проверяем актуальность кэша.
4. Если кэш не актуален, то отправляем запрос в СУБД на получение данных объекта
5. Получаем результат из СУБД и помещаем в кэш
7. Возвращаем объект из кэша.

(195) Кстати проверь для интереса скорость в транзакции. По уму через 20 секунд повторного чтения не должно быть

(197) Вообще можно сделать ХП в который передать текущую версию а он уже вернет набор всех таблиц если версия изменена.

18 проверить не получицца. Ключик тока один и там пока под 17 работает народ, так что тока на выходных.

(198) В транзакции ожидаемо быстро

Окончание замера "Подготовка объектного кэша" - Длительность = 1.56 с, Среднее = 0.00156 с
Окончание замера "Чтение с использованием объектного кэширования до 20сек" - Длительность = 0.016 с, Среднее = 0.000016 с
Окончание замера "Чтение с использованием объектного кэширования после 20сек" - Длительность = 1.95 с, Среднее = 0.00195 с
Окончание замера "Чтение отдельными запросами" - Длительность = 2.371 с, Среднее = 0.002371 с
Окончание замера "Чтение общим запросом" - Длительность = 0.094 с, Среднее = 0.000094 с

(201) Ух ты. А что так?

(201) Упс. Не быстро. Не увидел первую строку сразу)

(203) А что не так то?

Так, я нифига не понял произошедшее, надо оттестить с НачатьТранзакцию(), так? Я правильно понял?

(204) В (203) я писал про разницу между подготовкой кэша и чтением после 20сек.
А вот разница между даже подготовкой кэша и чтения отдельными запросами на лицо.

Почему НачатьТранзакцию() дает такой результат?

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

(201) Интересно а почему разница то до и после 20 сек.
Значит в 8 ке уровень рид комитед а не Repeatable read ?

(208) чей кэш? скульный или 1сный?

Для рассеивания сомнений привожу код теста еще раз

Сообщить(ТекущаяДата());
ВТранзакции = Истина;
Количество = 1000;
ИмяСправочникаБезГрупп = Метаданные.Справочники.ПодпискиКоманд2iS.Имя;
ИмяПоля = "ВерсияДанных";
//ИмяПоля = "ПометкаУдаления";
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ " + XMLСтрока(Количество) + "
|    Т.Ссылка
|ИЗ
|    Справочник." + ИмяСправочникаБезГрупп + " КАК Т";
МассивСсылок = Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("Ссылка"); //Готовим массив ссылок
Количество = МассивСсылок.Количество();
Сообщить("Размер выборки " + Количество);
Если ВТранзакции Тогда
   НачатьТранзакцию();
КонецЕсли;
УФ(сНачатьЗамер, Количество, "Подготовка объектного кэша");
Для Каждого Элемент ИЗ МассивСсылок Цикл
   Пустышка = Элемент[ИмяПоля];
КонецЦикла;
ДлительностьКэширования = УФ(сЗакончитьЗамер);
Если ДлительностьКэширования > 20 Тогда
   УФ(сСообщитьОбОшибке, "Длительность кэширования превысила 20 сек. Тест прекращен. Рекомендуется уменьшить количество элементов.");
   Перейти ~Конец;
КонецЕсли;

УФ(сНачатьЗамер, Количество, "Чтение с использованием объектного кэширования до 20сек");
Для Каждого Элемент ИЗ МассивСсылок Цикл
   Пустышка = Элемент[ИмяПоля];
КонецЦикла;
УФ(сЗакончитьЗамер);

УФ(сПодождатьЗаданноеВремя, 20);
УФ(сНачатьЗамер, Количество, "Чтение с использованием объектного кэширования после 20сек");
Для Каждого Элемент ИЗ МассивСсылок Цикл
   Пустышка = Элемент[ИмяПоля];
КонецЦикла;
УФ(сЗакончитьЗамер);

УФ(сНачатьЗамер, Количество, "Чтение отдельными запросами");
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
|    Т.Ссылка,
|    Т." + ИмяПоля + "
|ИЗ
|    Справочник." + ИмяСправочникаБезГрупп + " КАК Т
|ГДЕ
|    Т.Ссылка = &Ссылка";
Для Каждого Элемент ИЗ МассивСсылок Цикл
   Запрос.УстановитьПараметр("Ссылка", Элемент);
   Пустышка = Запрос.Выполнить().Выгрузить()[0][ИмяПоля];
КонецЦикла;
УФ(сЗакончитьЗамер);

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
|    Т.Ссылка,
|    Т." + ИмяПоля + "
|ИЗ
|    Справочник." + ИмяСправочникаБезГрупп + " КАК Т
|ГДЕ
|    Т.Ссылка В(&МассивСсылок)";
Запрос.УстановитьПараметр("МассивСсылок", МассивСсылок);
УФ(сНачатьЗамер, Количество, "Чтение общим запросом");
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
   Пустышка = Выборка[ИмяПоля];
КонецЦикла;
УФ(сЗакончитьЗамер);
Если ВТранзакции Тогда
   ОтменитьТранзакцию();
КонецЕсли;

(210) Я думаю SQL_ный все же.

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

(212) Ну кэш то на скуле имеется. При этом если транзакция Repeatable read то не смысла читать второй раз. По такому принципу должен быть и устроен транзакционный кэш 1с .
Из стать приведенной тобой
http://langslab.com/ebooks/prof-dev2/tome1/pr-dev-t1-ch04

Транзакционный кеш

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

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

Еще бы разобраться, где хранится внетранзакционный объектный кэш и где транзакционный. Пока 2 основных претендента rphost (у каждого свой кэш) и rmngr (общий для всех рабочих процессов). Логичнее всего конечно хранить в менеджере кластера rmngr и чтобы он был общий.

(215) Я говорил, что у скуля есть свой кэш. А ссылку привел на описание в статье, что скорость чтения в 1С в таком кэше не должна зависеть от времени.

(216) Ну все равно если они хранят и на сервере разницы по времени не должно быть. Если только они его не скидывают.
Тогда логичнее хранить по месту вызова.

Получил подтверждение от производителя, что
"в клиент-серверном режиме у клиента свой объектный кеш, а у сервера 1С свой".

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