일정에 맞춰서 작업을 진행하다보니 일단 빠르게 개발해보자라고 했던 쿼리들이 있습니다.
시간이 남는다면 빠르게 바꿔야지 했던 것들이 있었는데 꽤 다른 작업들이 일찍 끝나서 다시 수정해보기로 했습니다.
일단 기존에 작업했던 쿼리를 서브 쿼리로 짰습니다.
실행 시간이 처음에는 9초..조금씩 조금씩 변경하면서 4.5초.. 대로 줄이긴했는데 더 줄이고 싶었지요
실행 계획을 다시 살펴보기로 했습니다.
쿼리문의 목적은 대략 아래와 같습니다.
회사와 계약을 맺은 상품몰들의 전시 상품 목록과 기타 정보를 취득하는 것입니다.
전시 상품 목록은 현 시간을 기준으로 2년치 상품을 가져오게됩니다.
상품의 재고가 없을 수도 있고 기타 이슈로 인해서 상품몰측에서 전시를 안 할 수도 있기 때문에 각각의 상태값을 확인해서 유효한 상품을 가져옵니다.
아래가 처음에 만들었던 쿼리문의 실행 계획입니다.
눈에 띄는게 DEPENDENT SUBQUERY 입니다.
제가 만든 쿼리문이 상품몰의 기본정보를 담고있는 테이블을 기본으로 삼고있어요.
동시에 조회 시 전체 상품 목록이 (약 백만개) 담긴 테이블을 서브 쿼리로 사용하고 있고 WHERE 조건절에 상품몰의 고유 ID 로 전체 상품 목록 테이블에서 필터링하고 있습니다.
즉, 외부 쿼리에서 값을 전달받아 실행되는 서브 쿼리를 만들게 되었습니다. (약 4.5 초)
그리고 이런 경우를 DEPENDENT SUBQUERY (의존성 서브쿼리) 라고 합니다.
이렇게 하면 서브 쿼리가 먼저 실행되지 못하고, 서비 쿼리가 외부 쿼리의 결과 값에 의존하기 때문에 전체적인 성능 이슈가 생긴다고 합니다. 그래서 불필요하게 의존성이 묶여있는 경우라면 이런 의존성을 제거해줘야 한다고 합니다.


의존성 서브 쿼리를 JOIN 문으로 바꿔보도록 했습니다.
별도의 JOIN 문을 위한 구문을 만들어서 외부 쿼리문의 상품몰 고유 ID 로 INNER JOIN 을 완성했습니다.
(SELECT * FROM xxx_xxx_xxx INNER JOIN yyy_yyy_yyy USING (zzz) WHERE xxx.1 ~)
결과는 성공적인지 아닌지는 잘 모르겠으나..
일단 1.6 초대로 줄이긴했습니다.
DEPENDENT SUBQUERY 는 보이지 않습니다.


이번 기회를 통해서 성능 이슈를 발생시킬 수 있는 것들이 무엇이 있는지 스스로 알고 해결해본 소중한 경험이 되었습니다.
여튼 수정했고!
이번 수정된 내용을 다음주 배포에 반영할 수 있게 되었습니다.
다른 쪽도 살펴보고 같이 적용해볼려고 합니다.
그리고 지금 1.6 초대인데..더 줄일 수 있는 방법도 고민..도 잊지 않아야겠습니다.
'MySQL' 카테고리의 다른 글
| 데드락: 당황하지 말고 줄을 서시오 (0) | 2025.01.07 |
|---|