JPA 활용 2 수강중 - N+1 문제 해결 방법에서 뻗어나가기

jihunnit·2022년 6월 28일
0

TIL

목록 보기
3/16

실전 스프링부트와 JPA 활용 2편 을 듣다가, 강의 중간에 N+1 문제 (영한님은 1+N 문제라고도 말하시던데, 이게 사실 더 와닿는다.)에 대해서 다루었다.

강의에서는 jpql 쿼리문에 fetch join을 추가하여 문제를 해결하였는데, 이것 말고도 다른 해결 방법이 있을까 하다가
향로님의 블로그에서 @EntityGraph를 이용한 해결 방법에 대해서 알게 되었다.

둘 다 쿼리문이 나가는 횟수 자체는 같은 것 같지만, join 방식에서 fetch-join은 inner join, @EntityGraph는 outer join 임을 알게 되었다.

여기까지 하고 끝내면 재밌었겠지만, 뭔가 일관성을 추구하는 나는 난 더 좋은 방식 계속 쓸래. 그래서 저 둘 중 뭐가 더 좋은건데? 라는 질문에 도달하게 되었다.

그래서 공부도 추가로 할 겸, inner join과 outer join에 대해 공부하게 되었다.

사실 거창하게 글을 쓸 주제도 아니다.(기본적인거니까)
inner join은 교집합을 가져오고
outer join은 합집합(이라고 하지만 left, right, full에 따라 그 벤다이어그램에서 왼쪽을 A, 오른쪽을 B라고 할 때, A+(AnB),B+(AnB),A+B 임을 알게 되었다.

그래서 결국은 무어냐, inner join은 둘 다 데이터가 있을 떄 조회하고, outer join은 기준 테이블에 데이터가 있으면 다 조회된다는 것이다.

그러면 생각해볼 때, 애초에 AnB<=A 이며, AnB<=B 이고 당연히 AnB<=A+B임을 생각해볼 때, inner join을 하는 편이 어찌됐건간 데이터 자원을 조금 잡아먹든지, 테이블을 조금 가져오니까 조금이라도 빠르다던지 하는 어떤 장점이 있지 않을까?

하는 결론에 도달했다.

한 술 더 뜨면, fetch join이 @EntityGraph보다 이론상 성능이 안좋을 일은 없는거 아니야? 하는 결론에 도달했다.
(jpql을 따로 작성해야 한다는 불편함은 생략하겠다.)

정말 마지막 최종 결론.
나는 앞으로 N+1 해결할 때 fetch join 왕창 써야지.
이상 끝

profile
인간은 노력하는 한 방황한다

0개의 댓글