제가 아는 바로는

left join 이라서 안타는게 아닌거 같습니다.
해석기가  상황에따라(나름대로는 최적의 경로로) 사용할 인덱스를 결정하는데
님의 경우엔 판매일자의 인덱스를 사용하는 것 같네요(그 결과는 항상 옳은건 아닌 거 같더라구요)

where 조건절을 빼신다거나 쿼리에 변경이 일어나면 다른 인덱스가
또 사용될 수 도 있습니다...

where S.판매일자 between 을
-> where cast (S.판매일자 as char(8)) between ...식으로 cast를 사용해서
인덱스를 타지 못하게 하는 방법이 있습니다.
판매일자의 인덱스를 사용하지 못하게 하면
해석기는 다른 인덱스를 -나름대로- 차선책으로 선택합니다.
이 경우 아마도 원하시는 회원코드의 인덱스가 사용될 것 같네요

(인덱스 경로를 강제로 지정해주는-프로그램식으로-방식이 있다고는 들었는데
어떻게 하는 지는 잘 모릅니다.)

동문서답이었는 지 모르겠네요..

의견있으시면 리플 바랍니다.


egnes 님이 쓰신 글 :
: left join을 두게 쓰는 쿼리를 만들었는데.. 실행시키니 무려 12분이나 걸리네요.^^;;
:
: 일단, 예제로 실행시킨 쿼리를 보면...
:
: - 요놈은 5초 ----------------------------------------------------------------------------
: Statement: select M.회원코드, sum(S1.가격)
: from 멤버T M left join 판매T S1 On (S1.회원코드 = M.회원코드)
: where
: S1.판매일자 between '20040601' and '20040630'
: group by M.회원코드
:
: PLAN SORT (JOIN (M NATURAL,S1 INDEX (SALE_IDX01)))
: -----------------------------------------------------------------------------
:
: - 요놈은 1초 ----------------------------------------------------------------------------
: Statement: select M.회원코드,
: (select sum(S1.가격) from 판매T S1 where M.회원코드=S1.회원코드 and 판매일자  between '20040601' and '20040630')
: from 멤버T M
: order by M.회원코드
:
: PLAN (M ORDER MEMBERS_IDX01)
: PLAN (S1 INDEX (SALE_IDX01,RDB$PRIMARY51))
: -----------------------------------------------------------------------------
:
: 이렇게 나오는데.. left join 하면 index를 원래 안타는 겁니까?
: 그리고.. 제가 생각하기에는 두번째 쿼리가, 필드에 서브쿼리를 썻기에 더 느릴거 같은데 아닌가요?