개발자는 기록이 답이다

2024.04.05 - [SQL/쿼리 최적화] - Index를 활용한 10만건의 레코드 Join쿼리를 최적화하자 Index를 활용한 10만건의 레코드 Join쿼리를 최적화하자 마이페이지에서 유저가 발급받은 쿠폰 이력을 조회하는 기능을 구현해야 했습니다 해당 기능 구현 시 쿼리 최적화를 고려했던 과정을 포스팅 해보고자 합니다. 📌 무조건 쿼리 속도가 빠르면 strong-park.tistory.com 지난번에는 간단한 쿼리를 이용해서 인덱스를 통해 성능을 개선한 내용을 포스팅했습니다. 쿼리 수행 시간이 약 19ms정도 개선되었는데, 이 정도의 차이는 상당히 적은 차이입니다. 왜냐하면 네트워크 IO작업 한번만 해도 10ms가 넘는 경우가 있기 때문입니다. 그래서 좀 더 복잡한 쿼리를 만들기 위해서는 (진행중인..

마이페이지에서 유저가 발급받은 쿠폰 이력을 조회하는 기능을 구현해야 했습니다 해당 기능 구현 시 쿼리 최적화를 고려했던 과정을 포스팅 해보고자 합니다. 📌 무조건 쿼리 속도가 빠르면 되는 걸까? 쿼리 최적화를 고려한 기능을 만들면서 궁금한 점이 생겼습니다. 어떤걸 기준으로 쿼리 최적화가 됐다 라고 하는 것일까? 레코드 건수가 제일 작은게 드라이빙 테이블로 되는 것 같은데, 각 테이블 당 레코드 건수를 몇개를 넣어야 하는 것일까? 실행 계획을 보면서 인덱스를 이것저것 설정해보니, 속도는 빠르지만 ALL인 상황, 속도는 느리지만 index인 상황, filtered가 높아지거나 낮아지거나 등 여러 가지 상황에 따라 실행 계획이 바뀌는 것 같습니다. 그래서 처음에는 어떤 걸 기준으로 쿼리가 최적화되었다라고 봐야..