Вопрос риторический: как это должно работать ?

Мопед не мой (с)
Для тех кто читает темы по диагонали -- запрос из

ДоходыИРасходыСервер.ТекстЗапросаТаблицаПоступленияТоваров()

ВЫБРАТЬ
		УчетСебестоимости.АналитикаУчетаНоменклатуры.Номенклатура КАК Номенклатура,
		УчетСебестоимости.АналитикаУчетаНоменклатуры.СкладскаяТерритория КАК Склад,
		УчетСебестоимости.Период КАК Период,
		УчетСебестоимости.Регистратор КАК ДокументПоступления,
		ПриобретениеТоваровУслугТовары.ЗаказПоставщику КАК ЗаказПоставщику,
		СУММА(УчетСебестоимости.Количество) КАК Количество,
		СУММА(УчетСебестоимости.СтоимостьРегл) КАК Стоимость
	
	ИЗ
		РегистрНакопления.СебестоимостьТоваров КАК УчетСебестоимости
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ПриобретениеТоваровУслуг.Товары КАК ПриобретениеТоваровУслугТовары
		ПО УчетСебестоимости.Регистратор = ПриобретениеТоваровУслугТовары.Ссылка
			И УчетСебестоимости.ИдентификаторСтроки = ПриобретениеТоваровУслугТовары.ИдентификаторСтроки
	
	ГДЕ
		УчетСебестоимости.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
		И УчетСебестоимости.Активность
		И УчетСебестоимости.Организация = &Организация
		И УчетСебестоимости.РазделУчета В (
				ЗНАЧЕНИЕ(Перечисление.РазделыУчетаСебестоимостиТоваров.ТоварыНаСкладах),
				ЗНАЧЕНИЕ(Перечисление.РазделыУчетаСебестоимостиТоваров.СобственныеТоварыВПути))
		И ТИПЗНАЧЕНИЯ(УчетСебестоимости.Регистратор) = ТИП(Документ.ПриобретениеТоваровУслуг)
		
	СГРУППИРОВАТЬ ПО
		УчетСебестоимости.АналитикаУчетаНоменклатуры.Номенклатура,
		УчетСебестоимости.АналитикаУчетаНоменклатуры.СкладскаяТерритория,
		УчетСебестоимости.Период,
		УчетСебестоимости.Регистратор,
		ПриобретениеТоваровУслугТовары.ЗаказПоставщику
	
	ИМЕЮЩИЕ
		СУММА(УчетСебестоимости.Количество) > 0
		И СУММА(УчетСебестоимости.СтоимостьРегл) > 0

нормальный задел для будущих гениальных оптимизаций

(0)
Какие текущие показатели?

(0) На демо-базе работать будет.
Для презентаций и успешных переговоров на внедрении норм.

(0) откуда запрос?

"ГДЕ" можно/нужно заменить на "И"

(2)
Спасибо. Буду смотреть дальше.
Строк вроде немного. Что же оно дохнет то на join ?

ВЫБРАТЬ
	Количество(*)
ИЗ
	РегистрНакопления.СебестоимостьТоваров КАК СебестоимостьТоваров
ГДЕ
 ТИПЗНАЧЕНИЯ(СебестоимостьТоваров.Регистратор) = ТИП(Документ.ПриобретениеТоваровУслуг)	

= 1 млн строк "с копейками"

Всего в ССТ 40 млн строк

(0) Ну я думаю просто 1с пытается экономить на разработчиках, скорее всего такой код пишут студентики

(4)
1) ERP 2.5.22.114

Раньше запрос был проще,
а) строился по РегистрНакопления.СебестоимостьТоваров.Обороты
б) Сейчас его улучшили, чтобы достать "ЗаказПоставщику"

"Стек" вызовов

МенеджерОбменаЧерезУниверсальныйФормат.ПТиУ_РасширенныеДанныеИБ
РасшифровкаДопРасходов = ДоходыИРасходыСервер.РаспределениеРасходовНаСебестоимостьТоваров(ДанныеИБ.Ссылка);
ДоходыИРасходыСервер.ТекстЗапросаТаблицаПоступленияТоваров()

2) Про "ГДЕ" я не понял, прости.  :-(

3) Я разберусь. Тема скорее "а вдруг я чудак, смотрю не туда, думаю не головой и не вижу внутренный красоты запроса"

(5) план запроса надо смотреть. Вдруг он отсортировать во временной таблице твой регистр для мерджеджойна пытается...

Но план запроса вы так просто не соберете изза skip trace

(7) "2) Про "ГДЕ" я не понял..."
Соединение внутреннее -> все условия из ГДЕ можно перенести в  условия соединения.

(10)

Всегда считал, что оптимизатору в случае "ВНУТРЕННЕЕ СОЕДИНЕНИЕ" должно быть совершенно всё-равно находятся условия в ПО или в ГДЕ

(11) Кэш плана запроса поменяется, скомпилируется новый план, вдруг попадет в статистику - профит :-)

У меня mssqlprofiler болтается в панели задач по дефолту. Как вы без него живете ?

(12)

Вдруг это хорошо. Но на следующую ночь белые уйдут, придут красные и всё с начала.

(13)
а) Не сыпь мне соль на рану :-(
б) Я могу на всякие интимные вопросы отвечать, но не на все :-)

(0) ПО ВЫРАЗИТЬ(УчетСебестоимости.Регистратор КАК Документ.ПриобретениеТоваровУслуг) = ПриобретениеТоваровУслугТовары.Ссылка

Около х2 прироста на моей базенке

(15) а теперь верни назад и сравни.

(15) ВЫРАЗИТЬ(...) в условиях даст оптимизацию при чтении реквизитов составного типа через точку, а не ссылки.

Например:ПО ВЫРАЗИТЬ(УчетСебестоимости.Регистратор КАК Документ.ПриобретениеТоваровУслуг).Склад = ПриобретениеТоваровУслугТовары.Склад
Так будет быстрее.

А первый вариант без разницы. Разве не так?

(15) +1
(16), (17) Тут читайте https://its.1c.ru/db/v8std/content/654/hdoc

(0) Мне неизвестно случая, когда SQL проверит условие из Имеющие до выполнения слияния таблиц и проверки всех условий.

Т.к. полей Количество и стоимостьРегл в точно индексах таблицы нет, то надо сначала строить ВТ с необходимыми данными по регистру и её уже джойнить с табличной частью поступления.

(3) главное вовремя сбежать. лучше в Британию :)

(11) все правильно. просто кто-то один раз обжегся и все время на воду теперь дует.

(5) индексы для начала посмотри на таблице. есть в таблице индекс где регистратор первым идет?

и что значит дохнет? выполняется 30 мин или 2

(16)(17) правы
(15)(18) вы, видимо, неправильно понимаете что написано в ИТС. перечитайте, про разыменование в условиях соединения там ничего нет.  
А нет потому что в общем случае
"соединить ПО ЛЮБАЯ_ФУНКЦИЯ_ОТ_ПОЛЯ(ТАб1.полеХ)=Таб2.полеУ"
не использует индекс

(22)

1) Запрос (был вызван  из синхронизации данных) из (0) заблокировал 3 млн объектов за три часа, но так и не выполнился.
Был снят "как не оправдавший надежд"
Это в рабочей с живыми пользователями.

2) Спасибо, помогло
На тестовой базе добавил  фиктивное условие, чтобы заработал индекс "Период + Регистратор"

УчетСебестоимости.Период >= '01.01.2020'

Ибо раньше априори ничего нет.
Запрос отработал  за  2мин (в консоль я выводил только количество(*) из ВременнаяТ)


3) 2 мин это всё-равно печаль-печальная, ибо 1С выполняет этот запрос на каждый выгружаемый "Приобретение услуг и прочих активов" во время синхронизации данных.

4) Про индексы и статистику вероятно только к понедельнику получу ответ.
Что с индексом "Регистратор + НомерСтроки" я также без идей,
ибо доступа к SQL у меня, увы (а может к счастью) нет



ИТС нам говорит:
Регистр накопления
Основная таблица
Период + Регистратор + НомерСтроки
Регистратор + НомерСтроки

"И ТИПЗНАЧЕНИЯ(УчетСебестоимости.Регистратор) = ТИП(Документ.ПриобретениеТоваровУслуг)"

НЕ плохо для гуру

Наверное работает так же как:
УчетСебестоимости.Регистратор Ссылка Документ.ПриобретениеТоваровУслуг

(25)

Согласен. Я тоже иногда очень люблю типовой код.

Ну так отберите в курсор
проиндексируйте если набор данных больше 1 000.
Выразите тип поля связи в явном виде.
Выразить(УчетСебестоимости.Регистратор КАК Документ.ПриобретениеТоваровУслуг)

Я не спец большой. Просто вариант.

Большой шкаф громче падает.

Я не знаю.

(24) Чем поможет индекс по ссылке на таблице регистра, если её все равно сканировать из-за полей Количество и стоимостьРегл?

Да и история какая то странно выглядящая.
Нужен набор данных за всю историю.

(30) + Точнее как с учётом
...
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Документ.ПриобретениеТоваровУслуг.Товары КАК ПриобретениеТоваровУслугТовары
...
И ТИПЗНАЧЕНИЯ(УчетСебестоимости.Регистратор) = ТИП(Документ.ПриобретениеТоваровУслуг)
...

может не выполниться

ИМЕЮЩИЕ
        СУММА(УчетСебестоимости.Количество) > 0
        И СУММА(УчетСебестоимости.СтоимостьРегл) > 0

УчетСебестоимости.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
....
        И ТИПЗНАЧЕНИЯ(УчетСебестоимости.Регистратор) = ТИП(Документ.ПриобретениеТоваровУслуг)

Так задумано? ) Типа борьба с возвратами?

"УчетСебестоимости.Активность"

Для работы индексов не хватает только "Проведен"

Прилепили слева.
Получили перебор.
Курсор + индекс.

Так мидлы пишут наверное. Хотя и я тоже могу. Под настроение.

(24) Верно. Еще пару лет назад(в расширении) поставили на подобный запрос условие на период.

В обмене с БП, на каждый приход, идет безусловное(криво-условное) формирование громадной ВТ.
Жутко тормозило при объеме строк себеса с многими нулями. :(

(36)
Ну да. Условие на все время. + отбор по типу
= индекс частично заработает.

Ужастики какие-то, на третьем пентиуме базу крутите?
(24) 22млн записей, очень средний серверок
0,6секунды на этот запрос.

(0) Вообще-то все условия из ГДЕ нужно продублировать в условия соединения

(24) Если это вызывается для одного регистратора, то откуда тут всякие соединения с документами, а не выборка движений по одному регистратору?

(38)

Спасибо.

Посмотрел внимательно.
Действительно, объемы детские.
По идее join 1млн на 1млн строк.
Ничего не размножается, дублей в ИдентификаторСтроки - нет.

Что-то с индексами или статистикой или ...
Но это уже точно не сегодня.

(40)

Номер релиза указан в теме, "почему 1С сделала именно так",  мне сложно сказать, я буду разбираться и оптимизировать, если не смогут привести в чувство статистку индексов. Там не очень много кода, по идее ничего сложного быть не должно.

В релизе 2.5.24.65 по этому поводу изменений нет.

(30) тем, что индекс так не работает, как вы написали.

Всегда интересовало, что всеми движет, когда они верят в магию индексов. Которой нет.

(41) никакой адекватный sql не будет искать 1 млн. раз по индексу

Интересно , как 1с в типовой ерп может обяснить текст запроса в (0) …. без использования виртуальной таблицы ? Как же сертификат ?

Итоги  классикой собирают по линейной таблице и sum и group by и  having …. Чудны дела …

(0) Неудивительно что отлетает на join