Highload-оптимизация 1С: теория и практика на примере консолидированной отчетности группы "Магнит" и розничной аптечной сети "Магнит"

(1) Только что попробовал на разных компьютерах и серваках - где есть разница, где - нет (ну, там 5-10 процентов). Чаще всего разницы нет.

(3) Таблица значений тоже сохраняется на диск в сеансовые данные. Но это ерунда, по сравнению с временем, затрачиваемым при передачи больших ТЗ с сервера 1С на СУБД, Делается это пачками по 10 тысяч строк через BULK INSERT, но сильно легче от этого не становится. Причем пишется опять же во временную таблицу на диск.
Гораздо производительнее записать прямо на СУБД во временную таблицу, не спуская массив на сервер 1С.

(5)ЧекККМСерии - это табличная часть документа ЧекККМ. В нем Ссылка всегда строго типизирована, поэтому транслятор 1С запросов на СУБД просто проигнорирует Ваше "ВЫРАЗИТЬ(...)".
Проблема была в ЧекиККМ.Ссылка, а точнее соединение по этому полю. Транслятор 1С не видел, что идет соединение с полем одного типа, поэтому интерпретировал "ПО ЧекиККМ.Ссылка = ЧекиККМСерии.Ссылка" во что-то подобное
"ON CASE WHEN ЧекиККМ.RTRef = 0x... THEN ЧекиККМ.RRef END = ЧекиККМСерии._IDRef".
В свою очередь оптимизатор MS SQL 2017 увидел слева от "ON" нелюбимую конструкцию "CASE WHEN" и решил сделать HASH JOIN вместо очевидного LOOP JOIN. Поэтому система и считала хеши по всей таблице табличной части чеков ККМ, а когда их у Вас миллиарды, хеши считаются ооооочень долго.
Оптимизатор MS SQL 2012 и ниже делал еще хуже. Подробностей не помню, но был какой-то жесткий Lazy spool.

(6) Гораздо производительнее эту обработку кодом сделать в виде запроса 1С. Кто получал профильное программистское образование должны помнить, как мы реализовывали исполнение алгоритмах на разных абстракциях, вроде конечных автоматов. Так и в 1С - практически любой код можно переложить в запрос. А на больших объемах данных, обработка запросом гораздо производительнее.

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

(7) На самом деле, в изначальном тексте есть вложенный запрос, просто Вы его не видите. В плане выполнения же он есть: внешний запрос - это конструкция РАЗЛИЧНЫЕ, а вложенный - это соединение таблиц.
В изначальном варианте, соединялись две таблицы и на результате их соединения уже выполнялись РАЗЛИЧНЫЕ (конструкции HASH AGGREGATE или последовательно "SORT + STEAM AGGREGATE"). Причем это очень тяжелые конструкции, которые имеют дурную привычку лезть в TempDB (если ошибаются с ожидаемым количеством строк).
После оптимизации, тяжелая операция РАЗЛИЧНЫЕ выполняется на гораздо меньшем множестве строк, еще до его умножения на количество сегментов. Отличия производительности тем больше, чем больше сегментов.