각 테이블의 용도와 키, 인덱스 정보를 알려주세요.
검색 페이지의 조건과 테이블 항목들을 연결해서 표현해 주세요.
필수조건과 선택조건을 표현해 주세요.

^^답변감사합니다.

위 올린이미지와 쿼리문에 변경이 있어 다시올릴께요.

마농님이 말씀하신 표현해달라고 하신게 아래 내용이 맞는지 모르겠네요.

필수조건과 선택조건이라하시면 페이지가 열릴때 기본적으로 노출되는 리스트의 검색조건을 말씀하시는건가요?

그렇다면 필수조건이 없는걸로 봐야할것 같습니다.

저도 제가 직접개발한것이 아니라 소스분석하고 테스트하면서 하다보니 원하시는 답변을 정확히 못드릴것같네요. 죄송함다

소스도 복잡하고 인덱스도 좀 복잡하고 불필요한 인덱스를 잡은것도 있는것같구요.

- 소스노출문제로 인하여 삭제합니다. 양해바랍니다.^^ -

PK 가 실질식별자가 아닌 순번으로 되어 있네요.
실질식별자에 대한 UK 라도 설정이 되어 있어야 할텐데...
UK 를 설정한 것은 jgorder 뿐이네요.
그리고 인덱스는 각각의 컬럼별로 무수히 많네요?
그리고 메모 테이블의 키가 잘 표현이 안되어 있네요.

우선 실질 식별자를 알아야 테이블간의 관계를 파악할 수 있습니다.
제일 주가 되는 테이블이 주문테이블(jgorder) 인듯 하고
주문상품(prd_opt) 테이블이 있는 듯 한데 이 둘의 관계가 1:다 관계이겟죠?
회원(member) 과는 다:1 관계일 듯 하고
메모(memo) 와는 1:1 관계일까요? 1:다 관계일까요?

^^답변감사합니다.

1:1관계입니다.

우선 다른 관계는 문제 없는데. 상품과 주문의 관계가 문제입니다.
주문내역을 조회해야 하는데 상품 때문에 동일 주문내역이 여러행으로 조회되게 됩니다.
그래서 Group by 가 사용되구요.
데이터량도 많고 인덱스도 부적절하고.. 여러가지가 문제인데...
결국 화면 설계를 통해 검색량을 줄여야 합니다.
필수조건을 좀 더 늘리고
기간 조건을 필수조건으로 최근 1달 조회 식으로 강제로 박으세요.
p_source 는 앞에 % 를 빼거나 아예 like 가 아닌 이퀄 검색이 가능하도록 보완하세요.
그리고 페이징 처리를 하세요.
한페이지에 보일 만큼만 조회하세요.

^^ 답변감사합니다.

많은 도움되었습니다.

한가지만 더 여쭤봐도 될까요?

만약 쿼리를 변경 한다면 주문테이블이 드라이빙 테이블이 되어야겠지요?

아니면 조인없이 나머지 테이블이 루프안에 들어가서 운영되도록 설계하는것도

하나의 방법이 될수있을까요?

1. 조건이 주 테이블에만 있다면?
  주 테이블만 검색해서 페이징 처리하여 목록으로 보여주고
  상세화면 들어갔을 때 나머지 테이블 내역을 보여주면 되는데...
  조건이 모든 테이블에 고루 나뉘어 있다면 이렇게 하기 힘들죠.
2. 검색 범위를 가장 많이 줄여주는 조건이 있는 테이블이 드라이빙되어야 하는데.
  검색조건이 선택 조건이라 어떤 조건이 들어올지 모르므로
  어느 테이블이 드라이빙되는게 유리할 지 모릅니다.

^^ 답변감사합니다.

좋은하루 되세요.