운영중인 db 쿼리 성능 문제

Question

erd는 아래의 사진과 같습니다.현재 문제는 monitoring_time_log, monitoring_log, measure_detail, c_plan_history의 데이터를 가져올때 inner join으로 2 ~ 3단계 거쳐서 데이터를 가져옵니다. 이래서 그런지 모르지만, 쿼리 시간이 10초 이상이 소모가 됩니다.monitoring_log: 70189 rowmeasure_detail: 119148 rowmonitoring_time_log: 18173rowc_plan_history : 1952 row테이블 사이즈 순서대로 나열한 상태이구요.문제가 되는 쿼리의 inner join은 13번 사용되며, limit, offset으로 페이지처리중입니다. (페이지 처리를해도 쿼리시간이 10초이상 나옵니다.)explain analyze로 실행계획을보면 patient_candidate -> patientpatient_candidate -> patient_enrollment -> monitoring_time_log -> monitoring_log -> measure -> measure_detail이렇게 되어있고, monitoring_time_log, monitoring_log, measure_detail에서 cost가 높았습니다.저는 이부분을 해결하고자 떠올린 방법이 높은 cost의 데이터에 patient_id, patient_candidate_id, patient_enrollment_id를 부여하는게 가장 효율적이라 판단했는데. 역효과일까요? 팀장님은 별로 좋게 보지는 않으시더라구요.

장독깨기 · Answer

일단, 데이터 건 수로 봤을 때는 그렇게 오래 걸릴게 아닙니다.실행계획에서 인덱스를 제대로 태우고 있는지 확인하는 것이 중요한데요,좀 걸리는 것이 전부 저렇게 복합키로 PK 를 구성 해야만 하는지 좀 의문입니다.보통 로그나 내역 데이터는 저렇게 복합키로 구성할 필요없이 일련번호로 PK 를 잡습니다.그리고, 실제 데이터베이스는 어케 적용했는지 모르겠지만,ERD 로 보면 patient_enrollment 테이블에 patient_id 가 중복으로 들어가 있고,다른 테이블에도 중복으로 포함되어 있습니다.뭐 암튼, 복합키로 구성되어 있으면 빠짐없이 조건을 잘 걸어야 인덱스를 태울 수 있습니다.그리고, dependent subquery 가 포함되어 있으면 성능에 매주 안 좋습니다.혹 포함되어 있는지 확인해보는 것도 좋겠습니다.또한, 13번의 조인이 있다 하셨는데, 이 부분도 좀 이상합니다. 조인이 너무 많아요. ㅎ마지막으로, erdspace 로 작성한거 같은데요,관계선을 선택해서 이동시킬 수 있습니다.좀 더 깔끔하게 정리할 수 있을 겁니다. :)

운영중인 db 쿼리 성능 문제

1개의 답변

기술 목록