최적화 썸네일형 리스트형 (2) Mysql 실행 계획 분석 및 쿼리 튜닝 1. 서론2. 쿼리 응답 속도3. 부하 테스트4. 실행 계획 분석5. 쿼리 튜닝6. Spring에서 쿼리 힌트7. 결과8. 결론과 마무리 1. 서론지난 글에서 QueryDsl을 사용하여 DTO 조회로 극한의 성능 최적화를 진행했었습니다. 그때 결과적으로 약 6배 이상의 성능이 개선되었는데,데이터를 가져오는 양과 트랜잭션 범위의 차이에 의한 것이라고 생각했었습니다. 하지만 김영한님의 강의에서 요즘은 네트워크 성능이 좋아졌기 때문에 성능상 크게 차이가 나지 않을 것이라 하였고, 그렇다면 트랜잭션의 범위 차이와 user_roles 쿼리 한번의 추가로 6배나 차이가 생길까? 하는 의문이 계속 들었습니다. 그래서 테스트 했던 것을 다시 회고하는 중에, 엔티티로 모두 조회하는 쿼리에 포함되어 있던 distinct가.. 더보기 (1) Querydsl 성능 최적화와 테스트 목차1. 서론2. dto로 조회하기3. 성능 테스트4. 결론 1. 서론기존에 JPA를 사용하면서 생기는 N+1 문제를 모두 해결했었습니다. 또한 fetch join, batch_size를 사용하여 쿼리 횟수를 최소화하였으며, 중복되는 insert 쿼리를 jdbc template을 사용하여 bulk 쿼리로 대체하는 모든 최적화 과정을 마쳤었습니다. 하지만 DTO로 필요한 데이터만 가져와 최적화하는 것은 하지 않았기 때문에, 이 글에서 기존의 조회 API를 DTO로 조회하면 성능 차이가 얼마나 생길지, 적용 후 테스트 하고자 합니다. 2. DTO로 조회하기DTO로 조회하는 것을 기존에 하지 않았던 이유1:N 관계에 있는 컬렉션은 DTO로 바로 조회하지 못합니다. one 쪽 엔티티의 id(들)을 사용하여 ma.. 더보기 이전 1 다음
