[리팩토링] JPA 인덱스 추가로 조회 성능 개선

 

REFACTORING

JPA 인덱스 추가로 조회 성능 개선하기

목차

• 1. 작업 배경
• 2. 점검 기준
• 3. 인덱스 적용 전 확인
• 4. 적용 내용
• 5. 적용 후 확인
• 6. 참고
• 7. 배운 점

1. 작업 배경

인덱스는 DB가 데이터를 조회할 때 전체 테이블을 스캔하지 않고, 빠르게 원하는 행을 찾을 수 있도록 도와주는 자료구조다.

 

WHERE 조건으로 자주 사용되는 컬럼에 인덱스가 없으면, 데이터가 많아질수록 조회 성능이 급격히 저하될 수 있다. 리팩토링 단계에서 쿼리 로그를 확인하던 중 자주 조회되는 컬럼에 인덱스가 적용되지 않은 것을 발견했고, 조회 성능 개선을 위해 인덱스를 추가했다.

이번 작업의 핵심은 모든 컬럼에 무작정 인덱스를 추가하는 것이 아니라, 실제 조회 조건에 자주 사용되는 컬럼을 기준으로 필요한 인덱스만 선택하는 것이었다.

2. 점검 기준

인덱스 추가 대상은 자주 사용되는 WHERE 조건 컬럼을 기준으로 선정했다.

테이블	컬럼	이유
posts	user_id	게시물 목록 조회 시 항상 WHERE 조건으로 사용된다.
posts	reading_status	독서 상태별 통계 조회 시 WHERE 조건으로 사용된다.
posts	completed_date	기간별 통계 조회 시 BETWEEN 조건으로 사용된다.
memos	post_id	특정 게시물의 메모 목록 조회 시 항상 WHERE 조건으로 사용된다.
reminders	user_id	사용자별 리마인더 조회 시 WHERE 조건으로 사용된다.
reminders	reminder_time	스케줄러가 매분 알림 대상을 조회할 때 WHERE 조건으로 사용된다.

3. 인덱스 적용 전 확인

먼저 H2의 INFORMATION_SCHEMA.INDEXES를 조회해서 현재 테이블에 어떤 인덱스가 생성되어 있는지 확인했다.

SELECT * FROM INFORMATION_SCHEMA.INDEXES WHERE TABLE_NAME = 'USERS';

H2에서 USERS 테이블의 인덱스 정보를 확인하기 위한 SQL이다.

USERS 테이블 확인 결과, PK인 id에만 인덱스가 잡혀 있고 별도로 추가한 인덱스는 없는 상태였다.

 

이어서 POSTS, MEMOS, REMINDERS 테이블도 동일하게 확인했다.

SELECT * FROM INFORMATION_SCHEMA.INDEXES WHERE TABLE_NAME = 'POSTS';
SELECT * FROM INFORMATION_SCHEMA.INDEXES WHERE TABLE_NAME = 'MEMOS';
SELECT * FROM INFORMATION_SCHEMA.INDEXES WHERE TABLE_NAME = 'REMINDERS';

POSTS, MEMOS, REMINDERS 테이블의 인덱스 정보를 확인하기 위한 SQL이다.

 

세 테이블 모두 PK 인덱스만 존재하고, WHERE 조건으로 자주 사용되는 컬럼에는 별도 인덱스가 없는 것을 확인했다.

4. 적용 내용

User 엔티티

초기에는 User 엔티티에만 @Table의 indexes 속성으로 인덱스를 적용해둔 상태였다.

User 엔티티에만 인덱스가 적용되어 있던 초기 코드다.

Post 엔티티

Post 엔티티는 @Table 어노테이션에 indexes 속성이 없어 인덱스가 전혀 적용되지 않은 상태였다.

인덱스 적용 전 Post 엔티티 코드다.

@Table에 indexes 속성이 없어 별도 인덱스가 생성되지 않았다.

 

Post 엔티티에 user_id, reading_status, completed_date 인덱스를 추가한 코드다.

 

Memo 엔티티

Memo 엔티티에는 특정 게시물의 메모 목록을 조회할 때 자주 사용되는 post_id 컬럼에 인덱스를 추가했다.

@Table(name = "memos", indexes = {
    @Index(name = "idx_memos_post_id", columnList = "post_id")
})

Memo 엔티티에 post_id 컬럼 인덱스를 추가한 코드다.

 

Reminder 엔티티

Reminder 엔티티에는 사용자별 리마인더 조회에 사용되는 user_id와, 스케줄러가 매분 알림 대상을 찾을 때 사용하는 reminder_time 컬럼에 인덱스를 추가했다.

@Table(name = "reminders", indexes = {
    @Index(name = "idx_reminders_user_id", columnList = "user_id"),
    @Index(name = "idx_reminders_reminder_time", columnList = "reminder_time")
})

Reminder 엔티티에 user_id와 reminder_time 컬럼 인덱스를 추가한 코드다.

5. 적용 후 확인

인덱스를 추가한 뒤 애플리케이션을 다시 실행하고, H2에서 인덱스가 실제로 생성되었는지 다시 확인했다.

인덱스 적용 후 user_id, reading_status, completed_date 등 추가한 컬럼들에 인덱스가 생성된 것을 확인했다.

JPA의 @Index 설정은 엔티티 코드에 선언했다고 끝나는 것이 아니라, 실제 DB에 원하는 인덱스가 생성되었는지 확인하는 과정까지 함께 필요하다.

6. 참고

• jakarta.persistence.Index import가 필요하다.
• 로컬 H2 환경에서는 애플리케이션 재시작 시 자동으로 인덱스가 생성된다.
• 운영 MySQL 환경에서는 배포 시 DDL 적용 방식을 반드시 확인해야 한다.
• 인덱스는 조회 성능을 높일 수 있지만, insert/update 시 인덱스도 함께 갱신되므로 쓰기 성능에는 비용이 발생한다.

7. 배운 점

인덱스는 처음부터 모든 컬럼에 추가하는 것이 아니라, 실제로 WHERE 조건에 자주 등장하는 컬럼을 파악한 뒤 선택적으로 추가하는 것이 중요하다.

 

인덱스가 많아질수록 조회 성능은 좋아질 수 있지만, insert/update 시 인덱스도 함께 갱신되기 때문에 쓰기 성능은 떨어질 수 있다. 따라서 조회 패턴과 쓰기 빈도를 함께 고려해서 적용해야 한다.

 

또한 H2의 INFORMATION_SCHEMA.INDEXES를 통해 현재 적용된 인덱스를 직접 확인할 수 있다는 것도 알게 되었다. 로컬에서 JPA 엔티티 설정이 실제 DB에 반영되었는지 검증할 때 유용하게 사용할 수 있다.

정리하면, 인덱스는 “많을수록 좋은 설정”이 아니라 실제 조회 조건과 데이터 변경 비용을 함께 고려해서 선택적으로 적용해야 하는 성능 개선 도구다.