이 글은 인프런 김영한님의 Spring 강의를 바탕으로 개인적인 정리를 위해 작성한 글입니다.
쿼리 메소드 기능 3가지
- 메소드 이름으로 쿼리 생성
- 메소드 이름으로 JPA NamedQuery 호출
- @Query 어노테이션을 사용해서 리파지토리 인터페이스에 쿼리 직접 정의
메서드 이름으로 쿼리 생성
인터페이스에 메서드만 정의하면 알아서 DB로 쿼리가 날라간다.
public interface MemberRepository extends JpaRepository<Member, Long> {
List<Member> findByUsernameAndAgeGreaterThan(String username, int age);
}
위 메서드 이름에서 알 수 있듯이, 이름과 나이를 기준으로 회원을 정리하는 기능이다.
당연히 이 방식은 인공지능이 개입하는 것은 아니고 이름의 패턴으로 쿼리를 자동으로 작성해주는 것이다.
자세한 내용은 아래의 공식 사이트 방문을 추천
https://docs.spring.io/spring-data/jpa/reference/jpa/query-methods.html
- 조회 : find...By ,read...By ,query...By get...By
findHelloBy 처럼 ...에 식별하기 위한 내용(설명)이 들어가도 된다. - COUNT: count...By
반환타입 long - EXISTS: exists...By
반환타입 boolean - 삭제: delete...By, remove...By
반환타입 long - DISTINCT: findDistinct, findMemberDistinctBy
- LIMIT: findFirst3, findFirst, findTop, findTop3
이 기능은 엔티티의 필드명이 변경되면 인터페이스에 정의한 메서드 이름도 꼭 함께 변경해야 한다.
그렇지 않으면 애플리케이션을 시작하는 시점에 오류가 발생한다. 이렇게 애플리케이션 로딩 시점에 오류를 인지할 수 있는 것이 스프링 데이터 JPA의 매우 큰 장점이다.
NamedQuery
@Entity
@NamedQuery(
name="Member.findByUsername",
query="select m from Member m where m.username = :username")
public class Member {
//...
}
@Query(name = "Member.findByUsername")
List<Member> findByUsername(@Param("username") String username);
스프링 데이터 JPA를 사용하면 실무에서 Named Query를 직접 등록해서 사용하는 일은 드물다. 대신 @Query 를 사용해서 리파지토리 메소드에 쿼리를 직접 정의한다.
@Query
리포지토리 메소드에 쿼리 정의하기
public interface MemberRepository extends JpaRepository<Member, Long> {
@Query("select m from Member m where m.username= :username and m.age = :age")
List<Member> findUser(@Param("username") String username, @Param("age") int age);
}
List<Member> result = memberRepository.findUser("AAA", 10);
- @org.springframework.data.jpa.repository.Query 어노테이션을 사용 실행할 메서드에 정적 쿼리를 직접 작성하므로 이름 없는 Named 쿼리라 할 수 있음
- JPA Named 쿼리처럼 애플리케이션 실행 시점에 문법 오류를 발견할 수 있음
값, DTO 조회하기
단순히 컬럼 하나를 조회
@Query("select m.username from Member m")
List<String> findUsernameList();
JPA 값 타입( @Embedded )도 이 방식으로 조회할 수 있다.
DTO로 직접 조회
@Data
public class MemberDto {
private Long id;
private String username;
private String teamName;
public MemberDto(Long id, String username, String teamName) {
this.id = id;
this.username = username;
this.teamName = teamName;
}
}
@Query("select new study.datajpa.dto.MemberDto(m.id, m.username, t.name) from Member m join m.team t")
List<MemberDto> findMemberDto();
List<MemberDto> memberDto = memberRepository.findMemberDto();
DTO로 직접 조회 하려면 JPA의 new 명령어를 사용해야 한다.
파라미터 바인딩
select m from Member m where m.username = ?0 --위치 기반
select m from Member m where m.username = :name --이름 기반
import org.springframework.data.repository.query.Param
public interface MemberRepository extends JpaRepository<Member, Long> {
@Query("select m from Member m where m.username = :name")
Member findMembers(@Param("name") String username);
}
Member findMember = memberRepository.findMembers("AAA");
코드 가독성과 유지보수를 위해 이름 기반 파라미터 바인딩을 사용해야 한다.
컬렉션 바인딩
Collection 타입으로 in절 지원
@Query("select m from Member m where m.username in :names")
List<Member> findByNames(@Param("names") List<String> names);
List<Member> result = memberRepository.findByNames(Arrays.asList("AAA", "BBB"));
반환 타입
스프링 데이터 JPA는 유연한 반환 타입 지원
Member findMemberByUsername(String name); //단건
List<Member> findListByUsername(String name); //컬렉션
Optional<Member> findOptionalByUsername(String name); //단건 Optional
Member findMember = memberRepository.findMemberByUsername("AAA");
System.out.println("findMember = " + findMember);
List<Member> members = memberRepository.findListByUsername("AAA");
for (Member member : members) {
System.out.println("member = " + member);
}
Optional<Member> findOptional = memberRepository.findOptionalByUsername("AAA");
System.out.println("findOptional = " + findOptional);
공식 문서
https://docs.spring.io/spring-data/jpa/reference/repositories/query-return-types-reference.html#appendix.query.return.types
- 컬렉션
-결과 없음: 빈 컬렉션 반환 - 단건 조회
-결과없음: null 반환
-결과가 2건 이상: javax.persistence.NonUniqueResultException 예외 발생
단건으로 지정한 메서드를 호출하면 스프링 데이터 JPA는 내부에서 JPQL의 Query.getSingleResult() 메서드를 호출한다.
이 메서드를 호출했을 때 조회 결과가 없으면 javax.persistence.NoResultException 예외가 발생하는데 개발자 입장에서 다루기가 상당히 불편하다.
스프링 데이터 JPA는 단건을 조회할 때 이 예외가 발생하면 예외를 무시하고 대신에 null 을 반환한다.
페이징과 정렬
페이징과 정렬 파라미터
- org.springframework.data.domain.Sort : 정렬 기능
- org.springframework.data.domain.Pageable : 페이징 기능 (내부에 Sort 포함)
Sort
Sort는 데이터베이스 쿼리 결과를 특정 필드 기준으로 정렬할 때 사용된다. 정렬 기준은 필드명과 정렬 방향(오름차순 또는 내림차순)을 지정하여 정의한다.
- Sort.by(String... properties): 정렬할 필드를 지정한다.
- Sort.Order.asc(String property): 특정 필드를 오름차순으로 정렬한다.
- Sort.Order.desc(String property): 특정 필드를 내림차순으로 정렬한다.
// username을 오름차순으로 정렬
Sort sort = Sort.by("username").ascending();
// username을 내림차순, age를 오름차순으로 정렬
Sort sort = Sort.by(Sort.Order.desc("username"), Sort.Order.asc("age"));
Pageable
Pageable은 페이징 처리와 관련된 정보를 캡슐화하는 인터페이스로, 페이지 번호, 페이지 크기(한 페이지에 표시할 데이터 수), 그리고 정렬 정보를 포함한다.
Pageable 인터페이스는 PageRequest 클래스와 함께 자주 사용되며, 정렬 정보는 Sort 객체로 제공된다.
- (int) getPageNumber(): 현재 페이지 번호를 반환한다.
- (int) getPageSize(): 한 페이지에 표시할 데이터 수를 반환한다.
- (Sort) getSort(): 정렬 정보를 반환한다.
- PageRequest.of(int page, int size): 특정 페이지와 페이지 크기를 지정하여 Pageable 객체를 생성한다.
- PageRequest.of(int page, int size, Sort sort): 특정 페이지, 페이지 크기, 정렬 정보를 함께 지정하여 Pageable 객체를 생성한다.
- Page는 1부터 시작이 아니라 0부터 시작
특별한 반환 타입(Page, Slice)
- org.springframework.data.domain.Page : 추가 count 쿼리 결과를 포함하는 페이징
- org.springframework.data.domain.Slice : 추가 count 쿼리 없이 다음 페이지만 확인 가능(내부적으로 limit + 1조회)
- List (자바 컬렉션): 추가 count 쿼리 없이 결과만 반환
요약
- Page: 페이징된 결과와 함께 전체 데이터 개수(count)를 얻고 싶은 경우에 사용.
- Slice: 다음 페이지가 있는지 여부만 확인하고, 전체 데이터 개수는 필요하지 않을 때 사용.
- List: 단순히 페이징 없이 데이터를 조회할 때 사용.
Page
public interface Page<T> extends Slice<T> {
int getTotalPages(); //전체 페이지 수
long getTotalElements(); //전체 데이터 수
<U> Page<U> map(Function<? super T, ? extends U> converter); //변환기
}
Page는 페이징된 결과와 함께 전체 데이터 개수를 제공한다.
이는 페이징된 데이터를 가져올 때, 전체 데이터 수를 계산하는 count 쿼리가 추가로 실행된다는 의미이다.
이 count 쿼리를 통해 전체 페이지 수, 현재 페이지, 총 항목 수 등의 메타데이터를 제공받을 수 있다.
- 장점: 페이징된 결과를 제공하면서도 전체 데이터 수와 관련된 추가 정보를 얻을 수 있어, 전체 페이지 수나 현재 페이지가 몇 번째인지 등의 정보를 쉽게 파악할 수 있다.
- 단점: 추가적인 count 쿼리가 실행되기 때문에 성능에 영향을 줄 수 있다.
Page<Member> members = memberRepository.findByAge(25, PageRequest.of(0, 10));
int totalPages = members.getTotalPages();
long totalElements = members.getTotalElements();
Slice
public interface Slice<T> extends Streamable<T> {
int getNumber(); //현재 페이지
int getSize(); //페이지 크기
int getNumberOfElements(); //현재 페이지에 나올 데이터 수
List<T> getContent(); //조회된 데이터
boolean hasContent(); //조회된 데이터 존재 여부
Sort getSort(); //정렬 정보
boolean isFirst(); //현재 페이지가 첫 페이지인지 여부
boolean isLast(); //현재 페이지가 마지막 페이지인지 여부
boolean hasNext(); //다음 페이지 존재 여부
boolean hasPrevious(); //이전 페이지 존재 여부
Pageable getPageable(); //페이지 요청 정보
Pageable nextPageable(); //다음 페이지 객체
Pageable previousPageable();//이전 페이지 객체
<U> Slice<U> map(Function<? super T, ? extends U> converter); //변환기
}
Slice는 Page와 비슷하지만, 추가적인 count 쿼리를 실행하지 않는다.
대신, 다음 페이지가 있는지 여부만을 확인하기 위해 limit + 1의 데이터를 조회한다. 이를 통해 다음 페이지가 존재하는지 여부를 확인할 수 있다.
- 장점: count 쿼리가 없기 때문에 성능이 더 좋다. 필요한 데이터만 가져오고, 다음 페이지가 있는지 여부만을 확인하고 싶을 때 적합하다.
- 단점: 전체 페이지 수나 전체 데이터 수에 대한 정보가 제공되지 않는다.
Slice<Member> members = memberRepository.findByAge(25, PageRequest.of(0, 10));
boolean hasNext = members.hasNext(); // 다음 페이지가 있는지 여부
List
List는 페이징 처리가 전혀 없는, 단순한 데이터 목록을 반환한다.
Spring Data JPA에서 페이징이나 슬라이싱을 사용하지 않고, 그냥 데이터만 반환받고 싶을 때 사용된다.
- 장점: count 쿼리나 추가적인 메타데이터 처리가 없으므로 가장 간단하고 빠르다.
- 단점: 페이징 관련 정보가 전혀 제공되지 않는다.
List<Member> members = memberRepository.findByAge(25);
페이징과 정렬 사용 예제
Page<Member> findByUsername(String name, Pageable pageable); //count 쿼리 사용
Slice<Member> findByUsername(String name, Pageable pageable); //count 쿼리 사용 안함
List<Member> findByUsername(String name, Pageable pageable); //count 쿼리 사용 안함
List<Member> findByUsername(String name, Sort sort);
각각의 메서드는 페이징과 정렬을 다루는 방법이 조금씩 다르며, 반환 타입에 따라 추가적인 쿼리나 기능이 달라진다.
요약
- Page: 전체 데이터 수를 포함한 페이징된 데이터를 반환. 추가적인 count 쿼리가 실행된다.
- Slice: 다음 페이지가 있는지 여부만을 확인할 수 있는 페이징된 데이터를 반환. count 쿼리는 실행되지 않는다.
- List (with Pageable): 페이징된 데이터만 반환하고, count 쿼리는 실행되지 않는다.
- List (with Sort): 페이징 없이 정렬된 데이터만 반환한다.
Page<Member> findByUsername(String name, Pageable pageable)
이 메서드는 주어진 username에 해당하는 멤버들을 페이징하여 반환한다.
Page 타입을 반환하기 때문에, 전체 데이터의 수를 계산하는 추가적인 count 쿼리가 실행된다.
- 전체 페이지 수, 현재 페이지, 총 항목 수 등의 메타데이터를 포함하는 Page 객체를 반환한다.
- count 쿼리가 추가로 실행되어 전체 데이터 수를 계산한다.
Page<Member> result = memberRepository.findByUsername("John", PageRequest.of(0, 10));
int totalPages = result.getTotalPages();
long totalElements = result.getTotalElements();
List<Member> members = result.getContent(); // 실제 데이터 리스트
Slice<Member> findByUsername(String name, Pageable pageable)
이 메서드는 주어진 username에 해당하는 멤버들을 페이징하여 반환하지만, Slice 타입을 반환하기 때문에 추가적인 count 쿼리를 실행하지 않는다.
대신, 다음 페이지가 있는지 여부만 확인하기 위해 limit + 1 개의 데이터를 조회한다.
- 전체 데이터 수나 전체 페이지 수에 대한 정보는 제공되지 않는다.
- 다음 페이지가 있는지 여부만 알 수 있다.
- 성능상 이점이 있다(추가 count 쿼리가 없기 때문).
Slice<Member> result = memberRepository.findByUsername("John", PageRequest.of(0, 10));
boolean hasNext = result.hasNext(); // 다음 페이지가 있는지 여부
List<Member> members = result.getContent(); // 실제 데이터 리스트
List<Member> findByUsername(String name, Pageable pageable)
이 메서드는 주어진 username에 해당하는 멤버들을 페이징하여 반환하지만, List 타입을 반환하기 때문에 페이징된 데이터만 반환하고, count 쿼리는 실행하지 않는다.
- 페이징된 데이터만을 리스트로 반환한다.
- 추가적인 count 쿼리는 실행되지 않는다.
- Page나 Slice와 달리, 페이징 관련 메타데이터(예: 총 페이지 수, 다음 페이지 여부 등)는 제공되지 않는다.
List<Member> members = memberRepository.findByUsername("John", PageRequest.of(0, 10));
List<Member> findByUsername(String name, Sort sort)
이 메서드는 페이징 없이 정렬만 적용된 List를 반환한다. Sort 객체를 사용하여 결과를 특정 필드에 따라 정렬한다.
- 단순히 정렬된 결과 리스트를 반환한다.
- 페이징 기능은 제공되지 않으며, 전체 데이터를 정렬하여 반환한다.
List<Member> members = memberRepository.findByUsername("John", Sort.by(Sort.Order.desc("username")));
예시
public interface MemberRepository extends Repository<Member, Long> {
Page<Member> findByAge(int age, Pageable pageable);
}
//페이징 조건과 정렬 조건 설정
@Test
public void page() throws Exception {
//given
memberRepository.save(new Member("member1", 10));
memberRepository.save(new Member("member2", 10));
memberRepository.save(new Member("member3", 10));
memberRepository.save(new Member("member4", 10));
memberRepository.save(new Member("member5", 10));
//when
PageRequest pageRequest = PageRequest.of(0, 3, Sort.by(Sort.Direction.DESC, "username"));
Page<Member> page = memberRepository.findByAge(10, pageRequest);
//then
List<Member> content = page.getContent(); //조회된 데이터
assertThat(content.size()).isEqualTo(3); //조회된 데이터 수
assertThat(page.getTotalElements()).isEqualTo(5); //전체 데이터 수
assertThat(page.getNumber()).isEqualTo(0); //페이지 번호
assertThat(page.getTotalPages()).isEqualTo(2); //전체 페이지 번호
assertThat(page.isFirst()).isTrue(); //첫번째 항목인가?
assertThat(page.hasNext()).isTrue(); //다음 페이지가 있는가?
}
- 두 번째 파라미터로 받은 Pageable 은 인터페이스다. 따라서 실제 사용할 때는 해당 인터페이스를 구현한 org.springframework.data.domain.PageRequest 객체를 사용한다.
- PageRequest 생성자의 첫 번째 파라미터에는 현재 페이지를, 두 번째 파라미터에는 조회할 데이터 수를 입력한다.
여기에 추가로 정렬 정보도 파라미터로 사용할 수 있다. 참고로 페이지는 0부터 시작한다.
@Query 어노테이션을 사용하여 사용자 정의 쿼리를 작성할 때, 페이징된 결과와 함께 count 쿼리를 명시적으로 지정할 수 있다.
이를 통해 데이터를 조회하는 쿼리와 전체 데이터 개수를 계산하는 쿼리를 각각 다르게 지정할 수 있다.
@Query(value = "select m from Member m", countQuery = "select count(m.username) from Member m") Page<Member> findMemberAllCountBy(Pageable pageable);
value: 실제 데이터를 조회하는 JPQL 쿼리를 지정한다.
Page<Member> findMemberAllCountBy(Pageable pageable);
• value = "select m from Member m"은 Member 엔티티의 모든 레코드를 가져오는 쿼리이다.
countQuery: 페이징 처리를 위해 전체 데이터 수를 계산하는 count 쿼리를 지정한다.
• countQuery = "select count(m.username) from Member m"은 Member 엔티티의 username 필드를 기준으로 전체 레코드 수를 계산하는 쿼리이다.
• 일반적으로는 count(m)을 사용하지만, 여기서는 count(m.username)을 사용하고 있다. 하지만, 두 쿼리의 결과는 동일하다. countQuery는 페이징 처리에서 전체 페이지 수를 계산하기 위해 사용된다.
• 반환 타입이 Page<Member>인 메서드로, 페이징된 결과를 반환한다. • Pageable pageable 인자를 통해 페이지 번호, 페이지 크기, 정렬 조건 등을 전달할 수 있다.
• Page 객체는 페이징된 데이터 리스트와 함께 전체 데이터 개수, 총 페이지 수, 현재 페이지 번호 등의 정보를 포함한다.
페이지를 유지하면서 엔티티를 DTO로 변환하기
PageRequest pageRequest = PageRequest.of(0, 3, Sort.by(Sort.Direction.DESC, "username"));
Page<Member> page = memberRepository.findByAge(10, pageRequest);
Page<MemberDto> dtoPage = page.map(m -> new MemberDto(m.getId(), m.getUsername(), null));
- page.map() 메서드를 사용하여 Page<Member> 객체를 Page<MemberDto> 객체로 변환한다.
- 각 Member 객체는 MemberDto 객체로 매핑된다. 이 예제에서는 MemberDto 생성자에 Member의 id, username, 그리고 null을 전달하여 새로운 MemberDto 객체를 생성한다.
- null은 이 예제에서 Member 객체의 팀 정보를 나타내는데 생략했다.
- 이 과정에서 페이징 정보(예: 총 페이지 수, 현재 페이지, 다음 페이지 존재 여부 등)는 그대로 유지되며, 데이터만 변환된다.
벌크성 수정 쿼리
벌크 연산은 영속성 컨텍스트를 무시하고 실행하기 때문에, 영속성 컨텍스트에 있는 엔티티의 상태와 DB에 엔티티 상태가 달라질 수 있다.
벌크성 수정 및 삭제 쿼리는 @Modifying 어노테이션을 사용 사용하지 않으면 다음 예외 발생
- org.hibernate.hql.internal.QueryExecutionRequestException: Not supported for DML operations
벌크성 쿼리를 실행하고 나서 영속성 컨텍스트 초기화하려면 아래의 추가적인 속성을 부여해야 한다.
- @Modifying(clearAutomatically = true) (이 옵션의 기본값은 false )
이 옵션 없이 회원을 findById 로 다시 조회하면 영속성 컨텍스트에 과거 값이 남아서 문제가 될 수 있다.
만약 다시 조회해야 하면 꼭 영속성 컨텍스트를 초기화 하자.
@Modifying
@Query("update Member m set m.age = m.age + 1 where m.age >= :age")
int bulkAgePlus(@Param("age") int age);
권장하는 방안
-영속성 컨텍스트에 엔티티가 없는 상태에서 벌크 연산을 먼저 실행한다.
-부득이하게 영속성 컨텍스트에 엔티티가 있으면 벌크 연산 직후 영속성 컨텍스트를 초기화 한다.
@EntityGraph
엔티티를 조회할 때, 특정 연관된 엔티티들을 함께 로드하기 위해 사용하는 어노테이션이다.
이 어노테이션은 JPA의 EntityGraph 기능을 활용하여, N+1 문제를 예방하고, 쿼리 성능을 최적화하는 데 도움을 준다.
N+1 문제는 지연 로딩(Lazy Loading)으로 인해 발생하는 성능 문제로, 처음에 주 엔티티를 조회한 후 관련된 엔티티들을 개별 쿼리로 추가 조회하면서 총 N개의 쿼리가 실행되는 상황을 말한다.
이를 해결하기 위해 Fetch Join을 사용하면, 주 엔티티와 관련된 엔티티들을 한 번의 쿼리로 함께 로드할 수 있어 불필요한 쿼리 실행을 방지하고 성능을 최적화할 수 있다.
JPQL Fetch Join
@Query("select m from Member m left join fetch m.team")
List<Member> findMemberFetchJoin();
스프링 데이터 JPA는 JPA가 제공하는 엔티티 그래프 기능을 편리하게 사용하게 도와준다.
이 기능을 사용하면 JPQL 없이 Fetch 조인을 사용할 수 있다. (JPQL + 엔티티 그래프도 가능)
Entity Graph
//공통 메서드 오버라이드
@Override
@EntityGraph(attributePaths = {"team"})
List<Member> findAll();
//JPQL + 엔티티 그래프
@EntityGraph(attributePaths = {"team"})
@Query("select m from Member m")
List<Member> findMemberEntityGraph();
//메서드 이름으로 쿼리에서 특히 편리하다.
@EntityGraph(attributePaths = {"team"})
List<Member> findByUsername(String username)
EntityGraph 정리
- 사실상 FETCH JOIN 의 간편 버전
- LEFT OUTER JOIN 사용
JPA Hint
JPA에서 Hint는 데이터베이스 쿼리의 실행 방식이나 성능을 최적화하기 위해 JPA 프로바이더에게 전달되는 힌트를 의미한다.
힌트는 주로 쿼리 실행에 영향을 미치며, 쿼리의 성능 최적화, 캐싱 동작 제어, 읽기 전용 쿼리 설정 등 다양한 용도로 사용된다.
- 읽기 전용 쿼리 설정: 쿼리 결과가 변경되지 않는 경우, readOnly 힌트를 사용하여 성능을 최적화할 수 있다. 읽기 전용 힌트를 설정하면 JPA는 조회된 엔티티가 변경되지 않도록 관리하며, 이로 인해 메모리 사용량을 줄이고 성능을 향상시킬 수 있다.
- 쿼리 캐싱: 쿼리 결과를 캐시하도록 JPA 프로바이더에게 힌트를 줄 수 있다. 이를 통해 동일한 쿼리가 반복 실행될 때 데이터베이스 접근을 줄일 수 있다.
- 네이티브 SQL 힌트: 데이터베이스 프로바이더가 제공하는 특정 힌트를 사용할 수 있으며, 이 경우 힌트는 데이터베이스에 직접 전달되어 쿼리 최적화에 영향을 미친다.
@QueryHints(value = @QueryHint(name = "org.hibernate.readOnly", value = "true"))
Member findReadOnlyByUsername(String username);
@Test
public void queryHint() throws Exception {
//given
memberRepository.save(new Member("member1", 10));
em.flush();
em.clear();
//when
Member member = memberRepository.findReadOnlyByUsername("member1");
member.setUsername("member2");
em.flush(); //Update Query 실행X
}
쿼리 힌트 page
@QueryHints(value = { @QueryHint(name = "org.hibernate.readOnly", value = "true")},forCounting = true)
Page<Member> findByUsername(String name, Pageable pageable);
- forCounting : 반환 타입으로 Page 인터페이스를 적용하면 추가로 호출하는 페이징을 위한 count 쿼리도 쿼리 힌트 적용(기본값 true )
- findByUsername 메서드는 username 필드에 따라 Member 엔티티를 페이징하여 조회한다.
- 이 메서드가 실행될 때, Hibernate는 해당 쿼리를 읽기 전용으로 처리하며, 조회된 엔티티는 변경 불가능한 상태로 유지된다.
- 페이징 처리 시 사용되는 count 쿼리에도 readOnly 힌트가 적용되어, 전체 엔티티 개수를 계산하는 과정에서도 성능 최적화가 이루어진다
'Java Category > JPA' 카테고리의 다른 글
[Spring Data JPA] 새로운 엔티티인지 구별하는 방법 (0) | 2024.08.15 |
---|---|
[Spring Data JPA] 확장 기능 (0) | 2024.08.14 |
[Spring Data JPA] Spring Data JPA (0) | 2024.08.12 |
[JPA] 컬렉션 조회 최적화(OneToMany) (0) | 2024.08.11 |
[JPA] 지연 로딩과 조회 성능 최적화(ManyToOne, OneToOne) (0) | 2024.08.10 |