"N+1"이라는 단어를 외운 사람인지, fetch 전략의 트레이드오프(페이징 충돌·중복 결과)까지 잡는 사람인지를 가른다.
JPA N+1은 목록 조회 1번 뒤, 연관 엔티티를 항목별로 추가 조회하면서 select가 1+N로 폭증하는 현상이다. fetchType.EAGER로 바꾼다고 끝나지 않고, JPQL 결과 N건 각각에 대해 즉시 로딩 select가 따로 나갈 수 있다(여전히 N+1). fetch join이나 @EntityGraph로 _하나의 SQL_로 가져오게 만드는 것이 정공법이지만, 일대다 fetch join은 페이징과 결과 수 중복 문제가 따라온다. 그래서 케이스별로 fetch join, @EntityGraph, batch_size, 별도 조회 후 메모리 매핑 같은 전략을 골라 써야 한다.
p6spy/show_sql로 N+1을 찾아 fetch join으로 잡아본 경험이 있다면 측정→처치 흐름이 그대로 답변 후크가 된다
일대다 fetch join 페이징 문제를 @EntityGraph + batch_size 조합으로 풀어본 경험이 있다면 트레이드오프 이야기로 깊이가 생긴다
Repository 컨벤션에 "목록 조회는 fetch 전략을 명시한다" 같은 규칙을 둔 경험이 있다면 팀 운영 시각으로 연결할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.