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 이나 인덱스 활용이 어려운 조건입니다.
전체 자료를 모두 조회해야 하는 건가요?
최신 특정 기간 만큼의 자료만 조회한다던가?
페이징 처리를 해서 보여준다던가 하는 검색 대상을 줄여주는 기법이 필요할 수도 있습니다.