상황 설명

• 전체 조회 성능 향상을 위해 ElastiCache 도입
• cache에 조회한 페이지 정보 부재 시, DB에서 해당 페이지의 정보를 조회하도록 서비스 로직을 설계

문제 발생

• 특정 페이지를 처음 조회 시, 조회 데이터(Content)에는 index를 통해서 해결
• 그러나, Paging 처리를 하기 위한 Count query가 시간이 오래 걸리는 문제가 발생
• 정렬 기준을 id(PK) 로 해보았으나 성능이 여전히 좋지 않음

원인 분석

• 전체 상품 데이터는 약 500만개
• Count Query가 실행 될 때 테이블의 index를 사용하지만, 결국 Count 집계를 위해 모든 데이터를 scan하고 있었음

explain
select count(product_id)
from product
order by product_id;

                            **EXPLAIN 실행 결과 BTREE 기반의 인덱스를 사용 확인**

index 타입은 ORDER BY 절이 인덱스 순서와 일치할 때나, 집계 함수 (COUNT, SUM 등)를 사용할 때 발생할 수 있다.

해결 방법

1. 매일 자정 상품 정보가 업데이트 될 때, Cache에 상품의 전체 개수를 저장
2. 전체 상품 갯수 조회 쿼리 별도로 발생 → Cache에 저장
3. page 조회 쿼리를 날릴 때 마다 Cache 결과를 활용 → Cache에서 totalElement를 조회해오는 방식 도입. ⇒ 해당 줄의 글 필요??