Подскажите пожалуйста, как лучше оптимизировать запрос:

ВЫБРАТЬ
    РеализацияТоваровУслугТовары.Номенклатура КАК Номенклатура,
    СУММА(РеализацияТоваровУслугТовары.Количество) КАК Количество
ИЗ
    Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
ГДЕ
    РеализацияТоваровУслугТовары.Ссылка.Проведен = ИСТИНА
    И РеализацияТоваровУслугТовары.Ссылка.Дата МЕЖДУ &ДатаНач И &ДатаКон
    И РеализацияТоваровУслугТовары.Ссылка.ПервыйРаз = ИСТИНА

СГРУППИРОВАТЬ ПО
    РеализацияТоваровУслугТовары.Номенклатура

(55) этот "индексы в конкретных случаях могут замедлять неожиданно"?

Так в каких конкретных случаях индексы могут неожиданно замедлить выборку?

(56) 0-O ты где узнал, что внутренее соединение ухуджает производительность? Просто логически поразмыслил?

(57) Лишняя проверка - нагрузка на ПЦ, она избыточна. Нужно смотреть план исполнения но скорее всего в начале данные отберутся, а затем уже будут делаться агрегаты но я в этом не уверен на 100%, а по этому лучше внутреннее, чтобы память меньше расходовать.

(59) Ну там тупо есть проверка дополнительная при соединении, возможно что это микросекунды, но всё же...

(61) Я говорю это по конкретный случай, про то что ТЧ есть всегда, а то начнёте тут развозить...

(60) Да вот не лишняя она. Вот ты упертый товарищ.

(63) В левом соединении не лишняя, но я уже отписался нет ТЧ ставить левое. Это вы упёртые читать нужно что пишут.

(64) но я уже отписался нет ТЧ ставить внутреннее ( описался )

(65) Ты сдавал спеца по платформе или требования хоть раз смотрел?

(66) спеца не смотрел, требования чего?

Напоминаешь только только окрылившегося Программиста 1С, при этом только в своей голове.

(68) По моему совету (12), кроме внутреннего ещё есть претензии? Или все тут об астракциях думают, а не конкретный случай рассматривают? Если претензий нет, то кругом, раз, два

(67) МатЧасти (как говоришь) нахватался вроде, а как использовать не знаешь.

(70) Ну давай, жги, только не в лужу, а обоснованно, с примерами. Запрос (12) я накатал лёжа на диване в блокноте почти копипастом, про внутренне в тот момент не думал, так как в текущий момент в самописке ТЧ всегда заполнена. Ты давай умудренный знаниями покажи моменты где я не прав. Внутреннее мы уже обсудили, что ещё? Меня интересует утверждение "а как использовать не знаешь"

(61) план запроса смотрел?

(71) Всё просто, чем твой запрос отличается таким особенным от (0) ?

(73) С тобой всё понятно. Ну тогда напиши в какой запрос будет переведён (0) для SQL и тогда всё поймёшь.

(74) По твоему отличный прирост в производительности мы увидим? Тебе когда необходимо получить реквизит какого-либо ещё реквизита, тоже запрос пишешь?

(75) Смотря что, могу и через точку, если гарантированно SQL точкой не будет испорчен

ЛЕВОЕ

'SELECT
T2._Fld28317RRef,
CAST(SUM(T2._Fld28322) AS NUMERIC(26, 8))
FROM dbo._Document862 T1
LEFT OUTER JOIN dbo._Document862_VT28315 T2
ON (T1._IDRRef = T2._Document862_IDRRef) AND T2._Fld1704 = T1._Fld1704
WHERE ((T1._Fld1704 = P1)) AND (T1._Posted = 0x01 AND ((T1._Date_Time >= @P2) AND (T1._Date_Time <= @P3)))
GROUP BY T2._Fld28317RRef',N'P1 numeric(10),@P2 datetime2(3),@P3 datetime2(3)',0,'4015-04-01 00:00:00','4015-04-30 23:59:59'

ВНУТРЕННЕЕ
'SELECT
T2._Fld28317RRef,
CAST(SUM(T2._Fld28322) AS NUMERIC(26, 8))
FROM dbo._Document862 T1
INNER JOIN dbo._Document862_VT28315 T2
ON (T1._IDRRef = T2._Document862_IDRRef) AND T2._Fld1704 = T1._Fld1704
WHERE ((T1._Fld1704 = P1)) AND (T1._Posted = 0x01 AND ((T1._Date_Time >= @P2) AND (T1._Date_Time <= @P3)))
GROUP BY T2._Fld28317RRef',N'P1 numeric(10),@P2 datetime2(3),@P3 datetime2(3)',0,'4015-04-01 00:00:00','4015-04-30 23:59:59'

(0)
'SELECT
T1._Fld28317RRef,
CAST(SUM(T1._Fld28322) AS NUMERIC(26, 8))
FROM dbo._Document862_VT28315 T1
LEFT OUTER JOIN dbo._Document862 T2
ON (T1._Document862_IDRRef = T2._IDRRef) AND (T2._Fld1704 = P1)
WHERE ((T1._Fld1704 = @P2)) AND (T2._Posted = 0x01 AND ((T2._Date_Time >= @P3) AND (T2._Date_Time <= @P4)))
GROUP BY T1._Fld28317RRef',N'P1 numeric(10),@P2 numeric(10),@P3 datetime2(3),@P4 datetime2(3)',0,0,'4015-04-01 00:00:00','4015-04-30 23:59:59'

(80) Благодарствую! Некогда было подобное выкатить.

(80) Всё правильно. (73) Почувствуй разницу. Теперь объясни что будет делать база данных на запросе (79) и (80)

Никого не смущает, что в (0) суммируется количество в разных ед.измерения?

(82) Тесты, тесты со временем давай. Не очевидно, что SQL плохо в любом случае отработает.

(82) Я тебе точно говорю что то, что будет делать SQL, зависит от того, как ее оптимизатор обработает эти запросы. В 99% случаев они будут обрабатываться идентично.

(84) Тесты к (80) с благодарностью

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

(86) при левом соединении будет null что ошибка, в (0) не оптимально

план запроса в (0)
StmtText                                                                                                                                                                                                                                                                                                                                                                                                                  
--------                                                                                                                                                                                                                                                                                                                                                                                                                  
Compute Scalar(DEFINE:([Expr1005]=CONVERT(numeric(26,8),[Expr1004],0)))                                                                                                                                                                                                                                                                                                                                                    
  |--Parallelism(Gather Streams)                                                                                                                                                                                                                                                                                                                                                                                          
       |--Stream Aggregate(GROUP BY:([T1].[_Fld28317RRef]) DEFINE:([Expr1004]=SUM([partialagg1006])))                                                                                                                                                                                                                                                                                                                      
            |--Sort(ORDER BY:([T1].[_Fld28317RRef] ASC))                                                                                                                                                                                                                                                                                                                                                                  
                 |--Parallelism(Repartition Streams, Hash Partitioning, PARTITION COLUMNS:([T1].[_Fld28317RRef]))                                                                                                                                                                                                                                                                                                          
                      |--Hash Match(Partial Aggregate, HASH:([T1].[_Fld28317RRef]), RESIDUAL:([pepsico_erp].[dbo].[_Document862_VT28315].[_Fld28317RRef] as [T1].[_Fld28317RRef] = [pepsico_erp].[dbo].[_Document862_VT28315].[_Fld28317RRef] as [T1].[_Fld28317RRef]) DEFINE:([partialagg1006]=SUM([pepsico_erp].[dbo].[_Document862_VT28315].[_Fld28322] as [T1].[_Fld28322])))                                          
                           |--Nested Loops(Inner Join, OUTER REFERENCES:([T2].[_IDRRef], [Expr1007]) WITH UNORDERED PREFETCH)                                                                                                                                                                                                                                                                                              
                                |--Clustered Index Seek(OBJECT:([pepsico_erp].[dbo].[_Document862].[_Document862HPK] AS [T2]), SEEK:([T2].[_Fld1704]=[@P1]),  WHERE:([pepsico_erp].[dbo].[_Document862].[_Date_Time] as [T2].[_Date_Time]>=[@P3] AND [pepsico_erp].[dbo].[_Document862].[_Date_Time] as [T2].[_Date_Time]<=[@P4] AND [pepsico_erp].[dbo].[_Document862].[_Posted] as [T2].[_Posted]=0x01) ORDERED FORWARD)
                                |--Clustered Index Seek(OBJECT:([pepsico_erp].[dbo].[_Document862_VT28315].[_Documen862_VT28315_IntKeyInd] AS [T1]), SEEK:([T1].[_Fld1704]=[@P2] AND [T1].[_Document862_IDRRef]=[pepsico_erp].[dbo].[_Document862].[_IDRRef] as [T2].[_IDRRef]) ORDERED FORWARD)

+(89) фиговенько вставляется )

а в чем смысл СУММА(РеализацияТоваровУслугТовары.Количество)
зачем суммировать количество различной номенклатуры?

(91) Почему разной? Группировку по номенклатуре ещё никто не отменял

(89) Спасибо, можешь привести план запроса (79). Мне интересно ГДЕ ( все пункты ) накладывается до соединения сокрее всего. И в начале будет отбор по индексу Дата ( диапазон ), а далее наложены другие фильтра, и только в последнем моменте внутренее...

вы чё спорите?
в (8) правильный ответ

(94) Нафига делать отдельный индекс, которые будет ухудшать INSERT, если можно и так построить достаточно быстро работающий запрос? Почитай по OLTP где DBA прежде чем добавить индекс собирают информацию о там как это отразится на других частях системы, а тут давайте по каждому чиху индексов насоздадим... некошерно это.

(0) Усилить сервер ещё не предлагали? А то выборка по одной таблице медленно работает...

(0) Вариант 2. Подготавливать данные в отдельный регистр. Обновлять механизмом регистрации изменений.

(97) Уже даже не смешно. Из-за неправильно написанного запроса пытаются годзилу тут сваять...

(98) проясните, пожалуйста, несведущему в планах, что в (89) не так напланировано, по вашему. Спасибо!

(99) план одинаков практически у всех запросов

+ (100) я не сказал что он не правильный

(100) Кагбэ, это ожидаемо. Все приведённые запросы - одни и те же... из штанов.

(102) спор идет за левое соединение )

(100) используеться seek where, означает что отсутствует индекс, идет частичное сканирование таблицы . Далее идет нестед лупс, возможно он не должен там быть. Напишите пожалуйста количество ожидаемых и выводимых строк

(99) Я писал в (87) (103) За левое не идёт спора, я уже написал, если есть услуги в отдельной таблице то внутреннее.

(95) Ты умными словами не раскидывайся, везде нужно голову включать: нужно сравнить сколько раз добавляется документ, и сколько раз по нему отчет будет формироваться, после этого принимать решение по индексу.

PS Регистр по сути даст тот же тот же индекс только в отдельной таблице, и внезапно, падения производительности на этом практически не будет.

(106) Зачем раздувать базу? Зачем лишнее писать в доп таблицу? Внезапно много зачем

(104) на какой момент?

(92) тупанул чето

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

(110) к (108)

Идите все в регистры))) - они оптимизированы для запросов через 1С.

(107) Я, таки, одобряю ваш подход к ресурсам сервера. Гои могут подождать свои отчеты пару дней, а сервера нынче очень дороги.

(104) табл док, 12000, тч 11
вложенные циклы 144к
сортировка 0,009%

(112) Ты имеешь ввиду особенные таблицы в РСУБД? ( не только лишь все мало кто может это сделать :)

ого.Смотри у тебя на нестед лупсе просто пидец!

(114) А что за циферки будут для (79)?

не увлекайтесь, дайте поработать

(113) Очередной раздуватель из мухи слона?

(116) для него оптимально 5-6 выполнений. Оптимизатор пипец как просчитался. у тебя получается идет 11 раз частичное сканирование 12к строк таблицы(если не ошибаюсь). а сколько строк всего возвращается в итоге?

(113) Сначала проверь насколько увеличится база и насколько замедлится insert после добавления одного индекса по реквизиту с типом булево (допустим в таблицу с 100000 документов), потом расскажешь про мух и слонов.

(121) а зачем по булево индексировать, там же селективность никакая?

(122) Я думаю что этот индекс тупо будет проигнорирован в плане и увеличит время INSERT-а, будет занимать место на диске и да "гои" (113) так и не дождутся своего отчёта

(122) (123) А вы попробуйте из базы в 100000 записей выбрать 500 у которых это булево установлено. Вы тут теории двигаете, а я на практике проверял.

(124) Мы обсуждаем данный запрос или абстракцию? Перечитай (38) по поводу абстракций. Так и хочется сказать словами Лаврова.

(120) 250 строк на финише

+ (126) база ерп большая и старенькая, статистику обновлю еще гляну позже

(127) В принципе все что выше написали по поводу регистра и индексации верно, если что пишите на мейл, поковыряю планы.

(127) Спасибо за участие и пожалуйста выложи просьбу в (117), моего запроса в (12) только с INNER JOIN чтобы сравнить с (0)

Господа, мне кажется подход неверный изначально. Делать запрос к документу - моветон. Изначально должен быть запрос к Оборотному регистру накопления ибо это продажи, ибо это документ РТУ. Если конфа ERP тогда запрос по оборотному регистру ВыручкаИСебестоимостьПродажОбороты

Если это УПП то там есть оборотный регистр накопления ПродажиСебестоимость, делай запрос к виртуальной таблице ПродажиСебестоимостьОбороты

(130) Да только там данных изначально больше, дефрагментация таблицы может быть больше, индексы толще( можно конечно уповать на то что они в кэше ) и всё равно из-за поля ПервыйРаз соединять с таблицей Документ.РеализацияТоваровУслуг так что не вижу причин почему запрос не сделать так как в (12)

(131) Нет комментариев я в ехере

Прискорбно, что большинство 1сников не знают 1С.

(132) Что мешает ВЫБРАТЬ ПЕРВЫЕ 1 ?

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

(132) Поля ПервыРаз быть не должно, если это костыль статуса, то такой статус должен хранится в Регистре сведений

(132) Да и вообще что это за признак, косвенный признак что это первая продажа данному контрагенту? Тогда можно обойтись и без него.

Попробуй переделать запрос на -
ВЫБРАТЬ
    Док.Ссылка КАК Ссылка
    Поместить ВТ_Документы
ИЗ
    Документ.РеализацияТоваровУслуг КАК Док
ГДЕ
    Док.Проведен
    И Док.Дата МЕЖДУ &ДатаНач И &ДатаКон
    И Док.ПервыйРаз;
    
ВЫБРАТЬ
    РеализацияТоваровУслугТовары.Номенклатура КАК Номенклатура,
    СУММА(РеализацияТоваровУслугТовары.Количество) КАК Количество
ИЗ
    Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
ГДЕ
    РеализацияТоваровУслугТовары.Ссылка В (выбрать Т.Ссылка ИЗ ВТ_Документы КАК Т)

СГРУППИРОВАТЬ ПО
    РеализацияТоваровУслугТовары.Номенклатура

(139) по точке запятой предполагаю что это пакетный запрос, тогда не хватает ПОМЕСТИТЬ Т

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

делать нужно как правильно, а не тупо абы как лишь бы взлетело

Читаем (131) (135) (136) (137) (138)

(143) Автор пиши исчо ( фильтр не пропускает точное изречение )

(139) ну так там есть Поместить ВТ_Документы,
и именно таким методом я ускорял запросы когда внутри ТЧ дофига строк и идут фильтры на Ссылка.

(145) Это не тот случай. Запрос в (12) и не нужно временных таблиц, тем более через IN РеализацияТоваровУслугТовары.Ссылка В (выбрать Т.Ссылка ИЗ ВТ_Документы КАК Т)

PS: Ужас какой-то...

(142) тут у (0) есть костыль, и хотят его оптимизировать (146) не ужас

(147) Не ужас будет в другом запросе, но не в данном случае

(148) аа, ты хочешь тоже самое, но без ВТ. Да, можно и так.

(149) Я написал запрос в (12) только там внетреннее соединение поставить и это конечный вариант.

(124) "Если у нас есть реквизит типа Булево, который мы проиндексировали с целью ускорить получение информации, то это будет очень неэффективно. Потому что Булево имеет всего два значения, и если они равномерно распределены в таблице, то половина таблицы будет со значениями Истина, а другая половина - со значениями Ложь. В результате СУБД не будет использовать такой индекс, потому что она увидит, что ничего полезного она от этого индекса не получит. Подобный индекс будет использоваться только в том случае, если мы хотим выбрать, например, значение Ложь, и записей с таким значением очень мало. Например, 99% это Истина, и 1% это Ложь."

(151) Прочитай (8) потом (12). Потом перечитай свой пост внимательно и пойми что нужно думать над каждой конкретной ситуацией, а не кричать что "индексы в конкретных случаях могут замедлять неожиданно".

(152) Умник, я не кричу,а лишь привел выдержку из статьи компании 1С, так для размышления.

(152) и тебе в догонку (122)

(154) Последние два предложения из своей выдержки перечитай. (122) это как раз о случае когда таких записей примерно поровну.

(155) Если записей примерно поровну, то прям в выдержке указано: "равномерно распределены в таблице, то половина таблицы будет со значениями Истина, а другая половина - со значениями Ложь. В результате СУБД не будет использовать такой индекс"

(155) да про 122 согласен.