1. 우선 Group By 사용법이 이상합니다.
  - mysql 에서만 에러 안나는 구문입니다.
  - group by 를 정확하게 사용해야 하겠습니다.
  - group by 가 필요한지도 의문이구요?
2. 정렬구문의 Case 문은
  - 이미 조건절에서 걸러낸 조건을 case 에서 또 사용하므로
  - Case 문으로 정렬하는 것은 무의미합니다.
3. 속도개선은
  - 검색조건에 대한 인덱스가 있어야 하는데.
  - bb.df 나 aa.return2 는 왠지 변별력이 없는 조건일 것 같구요.
  - aa.tn LIKE '%12345678%' 조건은 '%' 가 앞에 있어서 인덱스가 있어도 탈 수 없는 조건이네요.
4. 정보가 부족합니다.
  - 각 테이블의 역할과 서로간의 관계
  - 각 테이블 전체 건수 및 조건을 만족하는 건수
  - 인덱스 정보
  - 사용되는 각 항목들의 특성
  - Group by 를 왜 사용했는지에 대한 고찰..

마농님 답변감사합니다.

해당사이트는 해외직구 사이트입니다. 

저도 최근에 타업체에서 관리하던것을 인계받은것이라 현재 로직분석중에 있는상황이라 아는정도까지만 기술해드릴께요.

s_order : 고객이 주문한내용

 item : 고객이 주문한 상품

s_member : 회원정보

s_item_memo : 주문한 상품에 대한 개별적인 메모테이블

위와같이 정의할수있겠네요.

추가적으로 말씀드리면 현재 많은 컬럼들에 대해서 인덱스를 잡아놨네요.

bb.df 나 aa.return2 <--- 이부분은 삭제정보입니다.

주문내역을 삭제했을시 디비에서 완전 사라지지 않고 값을 변경시켜서 데이터를 유지합니다.

like구문을 테스트했을시 '%123456789%' 이런식으로 테스트했을시 속도가 느린반면 '123456789%' 은 속도가 빠릅니다.

단 문제는 검색되는 데이터가 조금은 차이가 난다는것은 알겠는데, like구문대신 instr을 적용해도 속도가 느리네요.

방법이 없는걸까요?

속도 문제 이전에 무의미하게 사용된 Group by 부터 제거해 보세요.
메모테이블의 조인 조건도 이상하네요.
주문번호와 상품번호를 조인하고 있네요?
메모는 없을 수도 잇는것 아닌지요? 아우터 조인이 맞을 듯 하구요.
삭제 여부 항목은 변별력이 부족하여 큰 의미가 없습니다.
삭제 안된 자료가 훨씬 더 많을 것이므로.
해당 조회 조건(aa.tn)의 의미가 뭔가요?
이 항목의 특성과 조회조건의 의미 등을 분석하는 것으로 부터 시작해야 할 듯.
like 나 instr 이나 인덱스 활용이 어려운 조건입니다.
전체 자료를 모두 조회해야 하는 건가요?
최신 특정 기간 만큼의 자료만 조회한다던가?
페이징 처리를 해서 보여준다던가 하는 검색 대상을 줄여주는 기법이 필요할 수도 있습니다.

마농님 답변감사합니다.

위의 예시를든 검색조건은 단순히 하나의 검색조건이구요
해외직구사이트다보니 검색조건이 엄청많네요. ㅡㅡ휴~~

group by를 빼버리면 속도가 더 느려지는군요..

업체에선 전체자료를 모두조회하길원하고 있네요...

신경써주셔서 감사합니다.^^

좀더 열심히 봐야겠네요..

수많은 조건 중 한나만 제시하고 개선하라는 건 말도 안되는 질문이네요.
Group By 를 자꾸 속도 문제로만 접근하시네요.
Group By 는 속도문제와 별개입니다.
Group By 를 맞게 사용한 것인지가 중요합니다.

마농님 답변감사합니다.

프로그램특성상 많은 조건을 내세우지 못하는것 저의 불찰이지만 이곳에 오시는분들께  개선해주세요 라고 한적없습니다.

어떤결과물을 도출해달라고 한적도 없습니다.. 

단지 프로그램 초보자이기에 배워나가는 과정중 조언을 구하고자 할뿐입니다.

조언 감사드립니다.