Нужно получить запрос
документов с основаниями за период, а также даты оснований.
Как сделать оптимально, чтобы попасть в индекс:
1. Соединить _1SJourn с _1SJourn
или
2. Соединить _1SJourn <-> _1SCrdoc <->_1SJourn
?

Вот запрос который получился:
Declare @PERIODN Char(8)
SET @PERIODN = '20190101'

Select top 100
J.*,
TabRod.*,
JOsn.Date_Time_IdDoc as Date_Time_IdDoc_Osn
from
_1sJourn J (Nolock)
join _1scrdoc TabRod (nolock) on TabRod.mdid=0 and TabRod.ChildId = J.IdDoc
join _1sJourn JOsn (Nolock)
On  TabRod.ParentVal = 'O1  3M' +JOsn.IdDoc
Where J.Date_Time_IdDoc > @PERIODN
and J.SP652 <> '   0     0   '

Запрос 2:
Declare @PERIODN Char(8)
SET @PERIODN = '20190101'

Select top 100
J.*,
JOsn.Date_Time_IdDoc as Date_Time_IdDoc_Osn
from
_1sJourn J (Nolock)
join _1sJourn JOsn (Nolock)
On  J.SP652 =  '  3M ' +JOsn.IdDoc
Where J.Date_Time_IdDoc > @PERIODN
and J.SP652 <> '   0     0   '

Почему не пользуешь CHILD_DATE_TIME_IDDOC? Вроде как дату подчиненного как раз из него можно.

(3) мне нужна даты оснований, а не подчиненного

Ну так 1 джойн.... журнал и ссылки.. в ссылках дочерний с датой.. в журнале родитель с датой.

(4) нужные данные документов с основаниями + дата основания

Для начала: пп 1 и 2 из(0) не соответствуют запросам 1 и 2

(7)
П.1 соответствует запросу (2),
А п. 2 соответствует запросу (1)

"документов с основаниями за период"
Существительное "период" относится к документам или основаниям?

(9) к документам

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

(11) тогда схема - п.2 из (0)
но запрос 1 не соответствует задаче

в твоем понимании документ-основание - это родительский или подчиненный документ?

(12) родительский.

Может лучше запросе 2 использовать substring или right?
+ Добавить связь по deffype?

Если я правильно понял что (0) надо, то для 1sqlite выборка ЗаявокПокупателя для Реализаций в определенном периоде, с попаданием в индекс, выглядит так.
Поправь в соответствие с со своим sql диалектом, должно взлететь.


SELECT
    ЖурналПодчиненных.IDDOCDEF||ЖурналПодчиненных.IDDOC [ДокПодчиненный :Документ]
    ,Ссылки.PARENTVAL [ДокОснование :Неопределенный]
    ,ЖурналОснований.DATE||ЖурналОснований.TIME [ДатаВремяДокОснования]
FROM Журнал AS ЖурналПодчиненных
LEFT JOIN __1S_CRDOC AS Ссылки
    ON  Ссылки.MDID='   0'
    AND Ссылки.CHILDID=ЖурналПодчиненных.IDDOC
LEFT JOIN Журнал AS ЖурналОснований
    ON ЖурналОснований.IDDOC=substr(Ссылки.PARENTVAL,7)
WHERE ЖурналПодчиненных.date BETWEEN :НачДата AND :КонДата
AND  ЖурналПодчиненных.IDDOCDEF=:ВидДокумента.Реализация
AND  ЖурналОснований.IDDOCDEF=:ВидДокумента.ЗаявкаПокупателя


запрос (1) почти верен
вместо такой связи
TabRod.ParentVal = 'O1  3M' +JOsn.IdDoc
нужно
substring(TabRod.ParentVal, 7, 9) = JOsn.IdDoc
что бы индекс работал

select
  jПодч.iddoc [ПодчиненныйДок $Документ],
  jПодч.iddocdef ПодчиненныйДок_вид,
  jПодч.date_time_iddoc ПозицияПодчиненногоДок,
  cast(left(jПодч.date_time_iddoc, 8) as datetime) ДатаПодчиненногоДок,
  rtrim(ltrim(jПодч.docno)) НомерПодчиненногоДок,

  jОснов.iddoc [ДокОснование $Документ],
  jОснов.iddocdef ДокОснование_вид,
  jОснов.date_time_iddoc ПозицияДокОснования,
  rtrim(ltrim(jОснов.docno)) НомерДокОснования,
  cast(left(jОснов.date_time_iddoc, 8) as datetime) ДатаДокОснования

from _1sjourn jПодч (nolock)
join _1scrdoc cr (nolock) on cr.childid = jПодч.iddoc and cr.mdid = 0
join _1sjourn jОснов (nolock) on jОснов.iddoc = substring(cr.parentval, 7, 9)
where jПодч.date_time_iddoc > '20190201'

+
and jОснов.iddocdef = $ВидДокумента.НаименованиеВидаДокументаСКодом__3M

и что такое SP652?
неужели общий реквизит ДокОснование с отбором?

SP652 это документ-основание.
Как определить попадаю я в индекс? Как это выглядит в плане запроса?

(14),(15),(16) спасибо, попробую

Итоговый запрос (время выполнения 1-3 сек):
Declare @PERIODN Char(9)
Declare @PERIODK Char(9)
SET @PERIODN = '20190101'
SET @PERIODK = '20190331Z'


Select top 100
J.IdDoc,
JOsn.IdDoc,
JOsn.Date_Time_IdDoc as Date_Time_IdDoc_Osn
from
_1sJourn J (Nolock)
join _1scrdoc TabRod (nolock) on TabRod.mdid=0 and TabRod.ChildId = J.IdDoc
join _1sJourn JOsn (Nolock)
On  Substring(TabRod.ParentVal,7,9) = JOsn.IdDoc and JOsn.IDDOCDEF = 130
Where J.Date_Time_IdDoc Between @PERIODN  AND @PERIODK
and J.SP652 <> '   0     0   '
and J.IDDOCDEF = 130

Для информации время выполнения запроса 1: 3 мин 33 сек, запроса 2: 6 мин 5 сек.

(19) Это общий реквизит документов с галкой отбор ?
И тип <документ> ?

(18) )

(21) так тебя и подчиненные интересуют строго определенного вида?

(21)
JOsn.IDDOCDEF = 130
J.IDDOCDEF = 130
документы одного вида друг на друга ссылаются?

(19) "Как определить попадаю я в индекс? Как это выглядит в плане запроса?"
Главное, ты должен понимать в какой индекс собираешься попадать
В плане выполнения, в информации по вершине графа плана, смотришь аргумент.
Там будет что-то типа OBJECT(ИмяБазы.dbo.ИмяТаблицы.ИмяИндекса ...
вот и смотришь попал или нет

(26) да и важно посмотреть по каким полям ключа индекса, индекс отработал
seek:(условия,...)

(22) Да, все верно

(25) Да, вид документа-основания и подчиненного одинаковый

при наличии общего реквизита с отбором
Select top 100
J.IdDoc,
JOsn.IdDoc,
JOsn.Date_Time_IdDoc as Date_Time_IdDoc_Osn
from
_1sJourn J (Nolock)
join _1sJourn JOsn (Nolock)
On JOsn.IdDoc = right(J.SP652, 9)
Where J.Date_Time_IdDoc Between @PERIODN  AND @PERIODK
and J.SP652 like '  3M%'
and J.IDDOCDEF = 130

при наличии не общего реквизита или общего без отбора, есть еще вариант с использованием таблицы документа вместо _1scrdoc

и почему не пользоваться метапарсером?..

(32) Могу привести запрос с метапарсером (полный запрос достаточно длинный), это я тестировал в sql.
Index seek есть, но на key lookup тратится 33% времени.

Вот часть запроса с метапарсером:
SELECT
1 as Пометка,
РасходнаяНакладная.IDDOC [Документ $Документ.РасходнаяНакладная]
, $РасходнаяНакладная.СуммаВклНДС СуммаВклНДС
, $РасходнаяНакладная.НДС НДС_документа
, Cast(Left(Журнал.DATE_TIME_IDDOC, 8) AS datetime) as Дата
, MAX($РасходнаяНакладная.ТипНакладной) [ТипНакладной $Перечисление.ТипыРасходнойНакладной]
, MAX(Журнал.$ОбщийРеквизит.ДокументОснование) [ДокументОснование $Документ]
,:Ставка20 as ПравильнаяСтавка
,:Ставка18 as НеправильнаяСтавка
//, Журнал.DATE_TIME_IDDOC as Позиция
FROM _1SJOURN AS Журнал With (NOLOCK)
    join _1scrdoc TabRod (nolock) on TabRod.mdid=0 and TabRod.ChildId = Журнал.IdDoc
    join _1sJourn JOsn (Nolock)
   On  Substring(TabRod.ParentVal,7,9) = JOsn.IdDoc and JOsn.IDDOCDEF = $ВидДокумента.РасходнаяНакладная and JOsn.Date_Time_IdDoc >= :ДатаПереходаНаСтавку20
    INNER JOIN $Документ.РасходнаяНакладная AS РасходнаяНакладная With (NOLOCK) ON Журнал.IDDOC = РасходнаяНакладная.IDDOC AND Журнал.IDDocDef = $ВидДокумента.РасходнаяНакладная
    INNER JOIN $ДокументСтроки.РасходнаяНакладная AS РасходнаяНакладнаяСтроки With (NOLOCK) ON РасходнаяНакладная.IDDOC = РасходнаяНакладнаяСтроки.IDDOC
WHERE (Журнал.DATE_TIME_IDDOC BETWEEN :НачДата AND :КонДата~)
    AND ($РасходнаяНакладнаяСтроки.СтавкаНДС = :Ставка18)    
    AND Журнал.$ОбщийРеквизит.ДокументОснование <> '   0     0   '
    and Журнал.IDDOCDEF = $ВидДокумента.РасходнаяНакладная
    --Условие на ЮЛ--
GROUP BY РасходнаяНакладная.IDDOC
, $РасходнаяНакладная.СуммаВклНДС
, $РасходнаяНакладная.НДС
, Журнал.DATE_TIME_IDDOC

(30) что тут улучшено?

(30) проверил, тоже работает нормально

(35) по сравнению с чем?

(33) без лукапа не обойтись, если нужны поля таблицы на входящие в ключ индекса, и да - это затратная операция

(37) в последнем варианте lookup увеличился с 33 до 50 %. По времени примерно одинаково.

(39) мне не понятно какой запрос с каким сравниваешь?

Сравниваю (30) и (21)

group by какой-то бестолковый

а.. вижу, бестолкоый фильтр на таб часть и ставку ндс

можно выкинуть group by и хотя бы exists влепить в where

(41) в 30 не используется crdoc и должно быть меньше чтений страниц

(39) "lookup увеличился с 33 до 50 %"
Это ведь еще можно так трактовать: нагрузка на лукап не выросла, просто остальные операции улучшились.
Нужно смотреть не только относительные показатели но абсолютные

(34) А итоги по колонкам с какими то Суммами в РасходнаяНакладная есть?
Если есть - можно попробовать отсечь часть документов, если в них вообще нет Ставки НДС18.
ИМХО Это будет быстрее чем табличные части перебирать.

Судя по синтаксису база MSSQL. Добавь нужный тебе индекс в нужную тебе таблицу. А чтоб не вносить его после каждой реструктуризации, хэшируй MD файл и сравнивай с сохранённым в константе и пересоздавай его.

(44) exists вроде медленнее работать должен

(48) есть 3 нетипичных индекса, которые пересоздаются после реструктуризации отдельной обработкой.
Объясни подробнее, что значит хэшировать md и как пересоздать после реструктуризации?

(48) может быть ты про пересоздание файла DDS и индексы в нем?

(50)


Процедура ПриНачалеРаботыСистемы()

    бла бла бла

    MetaDataWork=СоздатьОбъект("MetaDataWork");
    MDHash = СокрЛП(СервисFormEx.ПолучитьХэшМД5(КаталогИБ()+"1cv7.md",1));  
    Если СокрЛП(Константа.MDHash) <> MDHash Тогда
        ТекстЗапроса = "CREATE UNIQUE NONCLUSTERED INDEX бла бла бла ";
        глВыполнитьЗапрос(глБДЗапрос,ТекстЗапроса);
        Константа.MDHash = MDHash;    
    КонецЕсли;
    бла бла бла

КонецПроцедуры

отполируй под себя

(52) ок, примерно тоже самое сейчас делается вручную. Ещё файл DDS кажется исправляется

(53) словарь исравлять не надо.

(54) (52) master.sp_statistics доработаны?

(55) у меня не было доработано. но у меня и клюшек уже, считай, нет.

Если просто добавить индексы то 7ка не запускается. Нужно или править DDS, или дорабатывать sp_statistics

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