|
![]() |
#1 |
Участник
|
Тогда уж (AdvanceId, JournalNum, RecId). Если в результирующей выборке не нужно значение RecId по LedgerJournalTrans, то можно попробовать переделать на exists join. Если в LedgerJournalTrans штатный кластерный индекс по RecId, то достаточно (AdvanceId, JournalNum).
|
|
|
За это сообщение автора поблагодарили: belugin (10), SCP_00 (1). |
![]() |
#2 |
Участник
|
Цитата:
Journal num, наверное тоже надо как included column,? |
|
![]() |
#3 |
Участник
|
Цитата:
Сообщение от belugin
![]() По поводу JournalNum согласен, по поводу RecID интересно. Если включить его (как included column) то результат будет независим от того, кластерный ли индекс по RecID или нет, или он как-то включит RecID два раза? Если нет, то может, стоит включить, чтобы гарантировать его нахождение там вне зависимости от кластерности RecID?
Journal num, наверное тоже надо как included column,? |
|
|
За это сообщение автора поблагодарили: belugin (10). |
![]() |
#4 |
Участник
|
Теоретически, отсортированный JournalNum может привести к ускорению с помощью Merge Join, но лучше посмотреть план.
Цитата:
|
|