[Refactor] 인덱스 기반 게시글 검색 성능 최적화

[earl9rey]

📌 Related Issues

closed #41

📄 Tasks

1. category + created_at 복합 인덱스 도입

post(category, created_at) 조합으로 인덱스를 추가해 WHERE category = ? ORDER BY created_at DESC LIMIT ?, ? 형태의 쿼리가 인덱스를 타도록 최적화했습니다. 게시판 특성상 카테고리별 최신순 조회가 가장 빈번한 검색 패턴이라, 페이징 조회 성능에 직접적인 개선 효과가 있다고 판단했습니다.

2. countQuery 분리로 페이징 COUNT 성능 최적화

searchPosts, searchAll 쿼리에 countQuery를 명시적으로 추가했습니다.

Spring Data JPA는 Page 객체 생성 시 COUNT 쿼리를 자동 생성하는데, 이 COUNT 쿼리가 불필요하게 복잡해지거나 정렬/조인 등이 포함되는 경우 성능 저하가 발생할 수 있기 때문에, SELECT COUNT(p.id) 형태의 단순한 COUNT 쿼리를 명시하도록 하여 불필요한 연산 비용을 줄이고 쿼리 플랜을 더 예측 가능하게 만들었습니다.

⭐ PR Point (To Reviewer)

검색 로직 자체를 변경하지 않으면서, DB 인덱스 도입과 COUNT 최적화를 통해 검색 페이지네이션 성능을 개선할 수 있도록 했습니다.

1. 복합 인덱스(category, created_at) 도입을 선택한 이유

현재 가장 자주 호출되는 페이징 형태는 '카테고리별 최신순 정렬' 패턴입니다.
기존에는 category 조건을 필터링한 뒤 created_at 기준 정렬을 수행할 때 정렬을 위한 별도 작업(filesort)이 발생할 수 있었는데, 복합 인덱스를 추가함으로써 정렬 + 필터링을 인덱스 레벨에서 처리할 수 있어 성능이 향상됩니다.

데이터가 많아질수록 차이가 커지고, 향후 사용자/게시글 증가를 대비해 구조적으로 적용한 최적화입니다.

2. countQuery 분리의 필요성

Spring Data의 Page는 내부에서 SELECT COUNT(*) 쿼리를 자동 생성하지만, 복잡한 JPQL 사용 시 COUNT 쿼리도 동일한 구조를 따라가서 성능 저하를 일으키는 경우가 있다고 합니다.
따라서 countQuery를 직접 명시하여 COUNT 연산을 좀 더 단순하고 빠르게 수행하도록 개선해보았습니다.

🔔 ETC

1. 현재 인덱스는 로컬 DB에만 적용된 상태입니다.

리팩토링 사항은 dev 브랜치에만 반영하기로 논의했습니다만
혹시라도 추후에 배포 환경에도 동일한 최적화를 적용할 경우, 아래 단계가 적용되어야 합니다!

① 인덱스 적용

CREATE INDEX idx_post_category_createdAt ON post(category, created_at DESC);

② 운영 DB 백업(RDS Snapshot 등) 생성

스키마 변경(인덱스 추가)은 테이블 락이 일시적으로 발생할 수 있어 백업이 권장된다고 하네요!

2. FULLTEXT 기반 검색 고려

LIKE 기반 검색 %keyword%는 기본적으로 인덱스를 타지 않아 데이터가 많아질 경우 성능 문제가 발생할 수 있는데, MySQL의 FULLTEXT INDEX + MATCH AGAINST 방식은 검색 성능 면에서 매우 큰 이점을 가지는 옵션이라고 합니다.
다만, 한글 FULLTEXT 검색 정확도 문제, 운영 DB 스키마 변경 범위 등을 고려해 이번 리팩토링에서는 인덱스 도입만 진행했습니다.

향후 FULLTEXT 기반 검색도 다음 단계로 고려할 수 있을 것 같아요!

[chaeyuuu]

pr을 꼼꼼히 남겨주셔서 이해가 쏙쏙 잘 되었습니다. 성능 개선까지!! 말씀해주신대로 FULLTEXT 기반 검색 고려는 TODO로 남겨놓으면 좋을거같네요. 고생 많으셨습니다!!!!

[chaeyuuu]

검색에서 전체 카테고리 대상이 아닌 8개 카테고리 제한이니 이 부분만 헷갈리지 않게 주석 변경해두면 좋을거같아요!!