먼저, 답변 감사드립니다. :)
인덱스에 대해 말씀을 꺼내 주셔서, Sale_IDX01 인덱스를 살펴보니 컬럼 순서가 잘못되어 있더군요;;
회원,가격,날짜. 이렇게 되어 있더라구요;; 다시, 회원,날짜,가격 순으로 정렬하니 0.05초걸립니다. ㅎㅎㅎ^^;;;

그런데, 여전히 [회원T] 테이블에서는 인덱스가 먹지 않네요. 흠;;

참.. 그리고, FireBird의 인덱스는 참 오묘하네요. 테스트 한다고 인덱스를 이리 저리 바꿔가며 해봤는데..
분명 똑같은 쿼리에 똑같은 인덱스 인데도,
어쩔때는 16초 25초, 5초.. 심지어 2분이상 걸리며 인덱스를 타지 않는 경우도 있네요.
너무 오묘해서 갈피를 못잡겠습니다. +_+.. 뭐가 뭔지.. 뭘 잘못한건지;;

tk 님이 쓰신 글 :
: 테이블 구조나,인텍스도 클러스터 넌클러스터 이것부터 보는것도 좋을뜻합니다.
:
:
: 일단 
: 회원코드만 넌클러스터 인텍스 만들경우
: select M.회원코드, sum(S1.가격)
:  from 멤버T M left join 판매T S1 On (S1.회원코드 = M.회원코드)
: and   S1.판매일자 between '20040601' and '20040630'
:  group by M.회원코드
:
: 날짜,회원번호  클러스터 인텍스 만들경우 ex CREATE ASCENDING INDEX  .... on (..... , .....)
:
: select M.회원코드, sum(S1.가격)
:  from 멤버T M left join 판매T S1 On S1.판매일자 between '20040601' and '20040630'
: and (S1.회원코드 = M.회원코드)   group by M.회원코드
:
: 보통 판매데이터특성상 제느낌에 하는 애기임니다.
: 간단하게 위처럼 형태만 버꺼두 속도차이는 좀 있을겁니다.
:
:
:
:
: 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를 원래 안타는 겁니까?
: : 그리고.. 제가 생각하기에는 두번째 쿼리가, 필드에 서브쿼리를 썻기에 더 느릴거 같은데 아닌가요?