![]() |
#1 |
Участник
|
![]()
Есть запрос
X++: 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; |
|
![]() |
#2 |
Участник
|
1. План запроса.
2. Так как count(LJTrans) >> count(LJTable) возможно более селективным будет какой-то индекс по LJTrans (AdvanceID, RecID?) (сравните селективность условий по табличкам на конкретных данных - вероятно при большом объеме count(posted)>>count(!posted)) |
|
|
За это сообщение автора поблагодарили: SCP_00 (1). |
![]() |
#3 |
Участник
|
Тогда уж (AdvanceId, JournalNum, RecId). Если в результирующей выборке не нужно значение RecId по LedgerJournalTrans, то можно попробовать переделать на exists join. Если в LedgerJournalTrans штатный кластерный индекс по RecId, то достаточно (AdvanceId, JournalNum).
|
|
|
За это сообщение автора поблагодарили: belugin (10), SCP_00 (1). |
![]() |
#4 |
Участник
|
Цитата:
Journal num, наверное тоже надо как included column,? |
|
![]() |
#5 |
Участник
|
Цитата:
Сообщение от belugin
![]() По поводу JournalNum согласен, по поводу RecID интересно. Если включить его (как included column) то результат будет независим от того, кластерный ли индекс по RecID или нет, или он как-то включит RecID два раза? Если нет, то может, стоит включить, чтобы гарантировать его нахождение там вне зависимости от кластерности RecID?
Journal num, наверное тоже надо как included column,? |
|
|
За это сообщение автора поблагодарили: belugin (10). |
![]() |
#6 |
Участник
|
Теоретически, отсортированный JournalNum может привести к ускорению с помощью Merge Join, но лучше посмотреть план.
Цитата:
|
|