Feature/160 : 브리핑 목록 조회 쿼리 튜닝

[swa07016]

🚀 개요

브리핑 목록 조회 쿼리를 튜닝했습니다.
732ms → 215ms → 60ms

⏳ 작업 내용

선행
개발 DB에 약 5년치 데이터를 INSERT 했습니다. (briefing 약 11만건, scrap 테이블 약 13만건)

초기 쿼리

• 쿼리) briefing 테이블과 scrap 테이블을 join하고 group by로 스크랩 개수를 집계
• 시간) 732ms
• 실행계획)
  • 드라이빙 테이블(briefing)에서는 Full Table Scan, 드리븐 테이블에선 briefing_id로 걸려있는 적절히 활용한 nested loop join 수행
  • 임시테이블에서 스크랩 개수를 집계하는 부분이나 File Sort로 정렬하는 부분보다는 briefing 테이블을 Full Scan하며 join하는 부분에서 오래 걸렸음 (Nested loop left join : 0.069..263 / Table scan on b : 0.0388 .. 130)

서브 쿼리로 집계 변경

• 쿼리) join과 group by를 걷어내고 스크랩 개수를 dependent subquery 형태로 변경 (예상과는 다르게 빨라짐)
• 시간) 215ms
• 실행계획)
  • 마찬가지로 briefing 테이블은 Full Table Scan, 그러나 서브쿼리가 모든 행에 대해 실행되는 게 아니라 LIMIT 20이 수행된 20건의 행에 대해서만 수행되어서 빨라짐. (loops=20, 보통 subquery 형태로 되어있으면 join으로 풀어내라고 알고있어서 배제하고 있었는데 해보니 더 빨라짐)

복합 인덱스 추가

• WHERE절과 ORDER BY절이 같이 인덱스를 탈 수 있게끔 (type, created_at DESC) 형태로 생성
• type컬럼은 카디널리티가 매우 낮은편이라 인덱스의 선행 컬럼으로 적합하지 않지만, 브리핑 도메인에서 가장 많이 호출되는 API의 쿼리이므로 해당 쿼리만을 위해서라도 가치가 있다고 판단했음.
• 시간) 60ms
• 실행계획)
  • briefing 테이블이 Full Table Scan하지 않고, 인덱스 레인지 스캔을 함.
  • 인덱스를 (type, created_at)으로 생성하는 것도 고려했는데 일케하면 해당 쿼리는 backward index scan을 하게 댐. backward index scan은 forward에 비해 약간의 성능저하가 있다고 알고 있어서 위처럼 생성함.

📝 논의사항

그.. 멀티모듈 분리한 이후에 쿼리로그가 잘 안찍히고, spotless 등 설정이 잘 적용이 안되는 것 같은데 검토 한 번 부탁드립니당 @CYY1007
자세한 설명은 회의때 해드리겠습니다