[QueryDSL] 7. 성능 최적화

올바른 쿼리를 작성하는 것만큼, 효율적인 쿼리를 작성하는 것도 중요하다. 이 편에서는 QueryDSL 사용 시 알아야 할 성능 최적화 기법을 다룬다.

fetch join으로 N+1 해결

N+1 문제는 JPA에서 가장 흔한 성능 문제다. 연관 엔티티를 지연 로딩으로 설정했을 때, 리스트를 조회한 뒤 각 항목의 연관 엔티티에 접근하면 건당 하나씩 추가 쿼리가 발생한다.

// N+1 발생 코드
List<Feed> feeds = queryFactory
        .selectFrom(feed)
        .fetch();

// 각 feed.getUser().getName() 접근 시마다 SELECT 쿼리 발생
for (Feed f : feeds) {
    f.getUser().getName();  // N번의 추가 쿼리
}

fetch join으로 해결한다.

// 해결: fetch join
List<Feed> feeds = queryFactory
        .selectFrom(feed)
        .join(feed.user, user).fetchJoin()
        .fetch();

이렇게 하면 Feed와 User를 한 번의 쿼리로 함께 가져온다. feed.getUser()에 접근해도 추가 쿼리가 발생하지 않는다.

여러 연관 엔티티를 함께 로딩

@ManyToOne, @OneToOne 관계는 여러 개를 동시에 fetch join할 수 있다.

List<Feed> feeds = queryFactory
        .selectFrom(feed)
        .join(feed.user, user).fetchJoin()
        .join(feed.weather, weather).fetchJoin()
        .fetch();

다만 @OneToMany 컬렉션 fetch join은 하나만 가능하다. 둘 이상의 컬렉션을 동시에 fetch join하면 MultipleBagFetchException이 발생한다.

exists 최적화

특정 조건의 데이터가 존재하는지 확인할 때, count를 쓰는 것은 비효율적이다.

// 비효율: 전체 행을 세고 0보다 큰지 비교
boolean exists = queryFactory
        .select(feed.count())
        .from(feed)
        .where(feed.user.id.eq(userId))
        .fetchOne() > 0;

count는 조건에 맞는 모든 행을 세야 하므로 데이터가 많을수록 느려진다. 존재 여부만 알면 되는데 전부 세는 것은 낭비다.

// 효율: 첫 번째 행만 찾으면 즉시 반환
boolean exists = queryFactory
        .selectOne()
        .from(feed)
        .where(feed.user.id.eq(userId))
        .fetchFirst() != null;

fetchFirst()는 내부적으로 LIMIT 1을 걸어서, 조건에 맞는 행이 하나라도 발견되면 즉시 반환한다. 데이터 양에 관계없이 빠르다.

벌크 연산

대량의 데이터를 수정하거나 삭제할 때, 엔티티를 하나씩 조회해서 변경하면 건당 UPDATE 쿼리가 발생한다. 벌크 연산은 하나의 쿼리로 여러 행을 한꺼번에 처리한다.

벌크 UPDATE

long updatedCount = queryFactory
        .update(user)
        .set(user.role, Role.INACTIVE)
        .where(user.lastLoginAt.before(Instant.now().minus(Duration.ofDays(365))))
        .execute();

1년간 로그인하지 않은 사용자의 역할을 일괄 변경한다. execute()가 실행한 뒤 영향받은 행 수를 반환한다.

여러 필드를 동시에 수정할 수도 있다.

long updatedCount = queryFactory
        .update(user)
        .set(user.role, Role.INACTIVE)
        .set(user.deactivatedAt, Instant.now())
        .where(user.lastLoginAt.before(cutoffDate))
        .execute();

벌크 DELETE

long deletedCount = queryFactory
        .delete(feed)
        .where(feed.createdAt.before(Instant.now().minus(Duration.ofDays(90))))
        .execute();

90일이 지난 피드를 일괄 삭제한다.

영속성 컨텍스트 주의

벌크 연산은 영속성 컨텍스트를 거치지 않고 DB에 직접 쿼리를 실행한다. 그래서 벌크 연산 후 영속성 컨텍스트에 캐시된 엔티티는 여전히 수정 전 상태를 가지고 있다.

// 1. 벌크 업데이트 실행
queryFactory
        .update(user)
        .set(user.role, Role.INACTIVE)
        .where(user.id.eq(userId))
        .execute();

// 2. 영속성 컨텍스트 초기화
entityManager.flush();
entityManager.clear();

// 3. 다시 조회하면 DB의 최신 상태가 반영됨
User refreshed = userRepository.findById(userId).orElseThrow();

flush()로 대기 중인 변경사항을 DB에 반영하고, clear()로 영속성 컨텍스트를 비운다. 이후 조회하면 DB의 최신 상태를 가져온다.

커버링 인덱스 활용

커버링 인덱스란, 쿼리에 필요한 모든 컬럼이 인덱스에 포함되어 있어서 테이블 접근 없이 인덱스만으로 결과를 반환할 수 있는 것이다.

// 1단계: 커버링 인덱스로 ID만 조회
List<Long> ids = queryFactory
        .select(feed.id)
        .from(feed)
        .where(feed.region.eq("서울"))
        .orderBy(feed.createdAt.desc())
        .offset(1000)
        .limit(10)
        .fetch();

// 2단계: ID로 엔티티 조회 (fetch join 포함)
List<Feed> feeds = queryFactory
        .selectFrom(feed)
        .join(feed.user, user).fetchJoin()
        .where(feed.id.in(ids))
        .orderBy(feed.createdAt.desc())
        .fetch();

1단계에서 인덱스만으로 대상 ID를 빠르게 추려내고, 2단계에서 소수의 ID로 실제 데이터를 가져온다. offset이 커도 인덱스 스캔만 하므로 성능이 크게 개선된다.

count 쿼리 분리

페이지네이션에서 전체 개수를 함께 반환해야 할 때, 조회 쿼리와 count 쿼리를 분리하는 것이 효율적이다.

public Page<Feed> searchPage(FeedSearchCondition condition, Pageable pageable) {
    List<Feed> content = queryFactory
            .selectFrom(feed)
            .where(
                    titleContains(condition.title()),
                    regionEq(condition.region())
            )
            .orderBy(feed.createdAt.desc())
            .offset(pageable.getOffset())
            .limit(pageable.getPageSize())
            .fetch();

    JPAQuery<Long> countQuery = queryFactory
            .select(feed.count())
            .from(feed)
            .where(
                    titleContains(condition.title()),
                    regionEq(condition.region())
            );

    return PageableExecutionUtils.getPage(content, pageable, countQuery::fetchOne);
}

PageableExecutionUtils.getPage()는 Spring Data가 제공하는 유틸리티다. count 쿼리를 Supplier로 받아서, 실제로 필요할 때만 실행한다. 첫 페이지에서 데이터가 page size보다 적으면 count 쿼리를 아예 실행하지 않는다.

count 쿼리에는 join이나 orderBy가 필요 없으므로, 조회 쿼리보다 단순하게 작성할 수 있다. 이것이 조회와 count를 분리하는 이유다.

자주 하는 실수

---