DB의 최적화 (쿼리 불러오는데 3초)

Question

해본적없는 코틀린해본적없는 Ktor간단한 명령어만 알고 있는 SQL 수준지금 제 눈 앞에는 7개의 조인과 서브쿼리들이 난장판을 치고 있네요..쿼리를 불러오는데 3초...이거를 줄여보라는 테스크를 받았습니다.브레이크 포인트를 잡고 문제가 생긴 곳은 확인은 완료했습니다.조인하는 부분에 예를들어 val selectList &#61; ㅂ .innerJoin(ㅅ) .join(ㅁ, JoinType.INNER) { ㅁ.isHaving.eq(true) and ㅁ.customer_id.eq( ㅅ.customer_id ) and ㅁ.qqq_id.eq( ㅅ.qqq_id ) }.leftJoin(ㄱ) .join(subQuery, JoinType.Left) ... customer_id들이나 자주 사용하는 부분을 Index가 안되어있길래 해줘도 성능이 아무것도 변하질 않네요.아직 캐싱이나 이런쪽으로 다른 방향으로 접근을 해줘야하는 걸까요.아니면 DB구조 자체를 튜닝을 해야할까요.선택지는 많은데 (물론 다 할 수 있지도 않습니다ㅠㅜ)회사 다니는 입장으로 까라면 까는건 당연하지만선배님들께서는 SQL 최적화 문제를 보았을 때 어떤 식으로 접근을 하는지 궁금합니다.

Clickin · Answer

ktor건 뭐건 결국 DB가 이해가능한 건 SQL밖에 없습니다.최종적으로 조립된 SQL을 가지고 실행계획 분석이 필요합니다.

yeori · Answer

쌩쿼리 갖고 실행계획 떠보는게 제일 빠릅니다.그리고 디비 설계가 칼같이 되어있지 않으면, jpa 돌렸을때 성능 제대로 안나오는 쿼리 많습니다.

MSSQL 튜너 · Answer

조건이 없으면 페이징해서 인덱스로 정확히 끊어서 가져오세요~

캐티 · Answer

다중에 그룹 조인을 하는 경우에 조인 순서와 매핑이 중요해요.사실 뭐 .. 만족 할 때 까지 실제 쿼리문을 작성하고 반복하여 튜닝이든 변경이든, 데이터 구조라도 변경을 해요!이와 달리 어떤 좋은 방법이 있겠나요.

basscraft · Answer

코틀린을 안해봐서 조심스럽습니다만...코틀린도 어짜피 최종 실행은 SQL로 돌아갈 것으로 생각되는데요서버로그나 DB로그를 보고 실제 실행 되는 쿼리를 가지고 실행계획을 떠보시는 것을 추천 드립니다.실제 실행시간은SQL 실행 시간 + 실행 결과 데이터 패치 시간 + 전송 시간 을 모두 포함입니다.우리가 사용하는 대부분의 DB 클라이언트는 자동으로 부분범위 처리를 하도록 되어 있습니다.select * from table명령을 실행하면 실제로는 select * from table limit 200; 이런식으로 일부만 조회 하도록 리미트가 추가 되서 실행 됩니다.우리가 짜는 프로그램에는 그런 기능이 없고 있어서도 안되죠만일 툴에서 실행한 쿼리는 바로 결과가 나온다면... 이 쿼리가 가져오는 전체 데이터가 얼마나 되는지도 한번 체크해 보세요.

DB의 최적화 (쿼리 불러오는데 3초)

5개의 답변

#ktor 목록