조회 쿼리 메서드 사용 시 불필요한 Join 이 사용되는 이유

devkimc·2023년 7월 3일

⏰ 성능 이슈 발생

쿼리 메서드를 작성하고 의도한대로 작동했는지 확인하고 있었습니다.
엔티티에 존재하는 applicant, group, status 필드를 조건으로 하여 데이터를 조회하는 쿼리 메서드입니다.

Repository

import org.springframework.data.jpa.repository.JpaRepository;

public interface SubscriptionRepository extends JpaRepository<Subscription, Long> {

    Optional<Subscription> findByApplicantIdAndGroupIdAndStatus(UUID applicantId,
                                                                Long groupId,
                                                                SubscriptionStatus status);
}

Entity

import jparest.practice.group.domain.Group;
import jparest.practice.user.domain.User;

@Entity
public class Subscription extends TimeBaseEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "subscription_id")
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY, optional = false)
    @JoinColumn(name = "group_id")
    private Group group;

    @ManyToOne(fetch = FetchType.LAZY, optional = false)
    @JoinColumn(name = "user_id")
    private User applicant;

    @Enumerated(EnumType.STRING)
    @Column(nullable = false)
    private SubscriptionStatus status;

    @Column(length = 40)
    private String message;

	...
}

제가 의도한 동작 방식은 조인을 하지 않고 Subscription 엔티티의 필드만으로 데이터를 조회하는 것이었습니다.
Join 이 사용된 이유가 궁금했습니다.

🔍 성능 이슈 원인

의심이 됐던 원인은
쿼리 메서드 작성 시, 조건으로 외래키(ApplicantId, GroupId) 값을 사용했고,
엔티티에는 연관관계의 객체(User, Group)가 있다는 것입니다.

쿼리 메서드가 외래키를 읽지 못하고 join 이 발생한다?
이렇게 생각하기에는 이해가 되지 않아서 쿼리메서드의 동작 과정을 찾아봤습니다.

쿼리 메서드 동작 과정

Property travelsal

Property expressions can refer only to a direct property of the managed entity, as shown in the preceding example. At query creation time, you already make sure that the parsed property is a property of the managed domain class. However, you can also define constraints by traversing nested properties.

쿼리메서드는 기본적으로 엔티티의 직접적인 속성만 참조할 수 있다고 합니다.
그 외에는 사용된 값을 구분하기 위해서 중첩된 속성을 순회하여 제약 조건을 정의한다고 합니다.

예시

List<Person> findByAddressZipCode(ZipCode zipCode);

위와 같은 예시에서 다음과 같은 알고리즘으로 동작합니다.

전체 이름이 엔티티에 존재하는지 찾는다.
존재하지 않을 경우, 카멜케이스 기준으로 머리와 꼬리로 분할하고 머리를 엔티티에서 찾는다.
존재하지 않을 경우, 분할 기준을 왼쪽으로 옮긴다.
머리가 엔티티에 존재하는 필드일 경우, 꼬리가 머리의 속성값이 맞는지 확인한다.
꼬리의 값이 머리에 존재하지 않는다면, 꼬리를 카멜케이스로 분할하여 동일한 알고리즘을 통해 트리를 계속 구축한다.

Address.Zip.Code 라는 값을 사용했을 경우의 속성 순환

Person 엔티티에서 AddressZipCode 찾기
AddressZip / Code - AddressZip 필드 찾기
Address / ZipCode - Address 필드 찾기
Address 에 ZipCode 속성이 있는지 확인하기
ZipCode -> Zip / Code -> ... 위와 같은 알고리즘 반복

나의 사용목적과 쿼리 메서드의 동작방식이 다르다

저의 경우 And 구분자를 사용하였기 때문에
쿼리메서드는 AppicationId, GroupId, Status 세개의 조건이 엔티티의 필드가 맞는지 확인했을 것입니다.
알고리즘을 통해 ApplicantId 과 GroupId 를 각각 Applicant / Id , Group / Id 로 분할합니다.
Applicant, Group 에 각각 Id 속성이 존재하는지 찾습니다.
존재하므로 Applicant.Id , Group.Id 와 일치하는 데이터를 찾습니다.
Applicant.Id, Group.Id 는 각각 User, Group 엔티티에 존재하는 기본키 필드입니다.
쿼리메서드는 다른 엔티티의 기본키를 사용한것을 확인하고, Join 을 사용해 다른 엔티티와 연결된 결과를 출력하려 한 것이라 예상합니다.

저는 필드의 외래키를 이용해서 조건에 맞는 결과를 조회하고 싶었습니다.
그러나 쿼리메서드는 필드의 직접 속성을 사용하는 것이 기본 동작방식이고, 그 외에는 속성 순환을 통해 Join 으로 데이터를 조회하기 때문이었습니다.

🔑 성능 개선 방법

1. 외래키 대신 연관 관계의 엔티티 사용

쿼리 메서드가 원하는 조건 사용 방식은 엔티티의 직접적인 속성 사용입니다.
즉, 외래키인 id 값으로 조회하지 않고 연관 관계에 있는 엔티티를 매개변수로 사용하면 Join 을 사용하지 않습니다.

    Optional<Subscription> findByApplicantAndGroupAndStatus(User applicant, Group group, SubscriptionStatus status);

단점은 클라이언트로부터 전달받는 값을 사용해서 조회하는 상황이 있을텐데, id 값으로 엔티티를 조회한 후에 매개변수로 사용해야 한다는 점입니다.
쿼리가 추가되는 단점이 생깁니다.

2. JPQL

쿼리 메서드 대신에 JPQL 을 사용하면 필드의 id 값 만으로도 Join 을 사용하지 않고 결과를 가져올 수 있습니다.

    @Query("SELECT s FROM Subscription s " +
            "WHERE s.applicant.id = :applicantId AND s.group.id = :groupId AND status = :status")
    Optional<Subscription> findByApplicantIdAndGroupIdAndStatus(@Param("applicantId") UUID applicantId,
                                                                @Param("groupId") Long groupId,
                                                                @Param("status") SubscriptionStatus status);