개발자는 기록이 답이다

추후에 MySQL에서 파티셔닝을 사용하게 될때 참고하면 좋을 듯하여, 작년에 면접준비를 위해 노션에 정리했던 내용 일부 가져왔습니다.  📌 레인지 칼럼 파티셔닝 전략을 사용한 이유 큰 틀로 보면 파티션의 종류로 총 4가지가 있지만, 이력 데이터를 범위 기반으로 분리하기 위해 레인지 파티션을 사용했습니다.레인지 파티션리스트 파티션해시 파티션키 파티션특히, 이체 내역은 기간 범위에 따라 조회하는 경우가 많기 때문에 파티션 프루닝 을 할 수 있도록 날짜와 시간 에 맞게 논리적으로 테이블을 분할할 수 있도록 설정했습니다.  그리고 레인지 파티션 중에서도 Range Column Partioning을 사용한 이유는 요구사항에 따라 연도와 월별 기준으로 데이터를 추출해야 하기 때문입니다.Range 의 경우 파티션..

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

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