А как бы его так?

[SCP_00]

Есть запрос

 select firstonly RecId from ledgerJournalTableC
                        index hint PostedJournalNumIdx
                        where ledgerJournalTableC.JournalType   == ledgerJournalTable.JournalType
                           && ledgerJournalTableC.Posted        == NoYes::Yes
                    join RecId from ledgerJournalTransC
                        where ledgerJournalTransC.JournalNum    == ledgerJournalTableC.JournalNum
                           && ledgerJournalTransC.AdvanceId     == ledgerJournalTrans.AdvanceId
                           && ledgerJournalTransC.RecId         != ledgerJournalTrans.RecId;

PostedJournalNumIdx - индекс по journalType, posted, и journalnum. И все бы хорошо, но запрос работает слишком долго, овер 5 мин на строку. Я переписал его для квери, стало чуть быстрей, но недостаточно. Как его еще ускорить ? Уже незнаю куда смотреть...

[belugin]

1. План запроса.
2. Так как count(LJTrans) >> count(LJTable) возможно более селективным будет какой-то индекс по LJTrans (AdvanceID, RecID?) (сравните селективность условий по табличкам на конкретных данных - вероятно при большом объеме count(posted)>>count(!posted))

[Alexius]

Цитата:

Сообщение от belugin

Так как count(LJTrans) >> count(LJTable) возможно более селективным будет какой-то индекс по LJTrans (AdvanceID, RecID?)

Тогда уж (AdvanceId, JournalNum, RecId). Если в результирующей выборке не нужно значение RecId по LedgerJournalTrans, то можно попробовать переделать на exists join. Если в LedgerJournalTrans штатный кластерный индекс по RecId, то достаточно (AdvanceId, JournalNum).

[belugin]

Цитата:

Сообщение от Alexius

Тогда уж (AdvanceId, JournalNum, RecId). Если в результирующей выборке не нужно значение RecId по LedgerJournalTrans, то можно попробовать переделать на exists join. Если в LedgerJournalTrans штатный кластерный индекс по RecId, то достаточно (AdvanceId, JournalNum).

По поводу JournalNum согласен, по поводу RecID интересно. Если включить его (как included column) то результат будет независим от того, кластерный ли индекс по RecID или нет, или он как-то включит RecID два раза? Если нет, то может, стоит включить, чтобы гарантировать его нахождение там вне зависимости от кластерности RecID?

Journal num, наверное тоже надо как included column,?

[YoungPadawan]

Цитата:

Сообщение от belugin

По поводу JournalNum согласен, по поводу RecID интересно. Если включить его (как included column) то результат будет независим от того, кластерный ли индекс по RecID или нет, или он как-то включит RecID два раза? Если нет, то может, стоит включить, чтобы гарантировать его нахождение там вне зависимости от кластерности RecID?

Journal num, наверное тоже надо как included column,?

Вот тут человек пишет, что в не кластерный индекс для ссылки добавляются все поля кластерного индекса. А если какое-то поле уже присутствует, то оно повторно не добавляется.

[Alexius]

Цитата:

Сообщение от belugin

Journal num, наверное тоже надо как included column,?

Теоретически, отсортированный JournalNum может привести к ускорению с помощью Merge Join, но лучше посмотреть план.

Цитата:

Сообщение от belugin

Если нет, то может, стоит включить, чтобы гарантировать его нахождение там вне зависимости от кластерности RecID?

Можно, только у автора топика похоже АХ 2009, где их нет: AX 2009. Преобразование числа в текст