https://gukin.dev/tags/pagination/ Recent content in Pagination on Gukin Han Hugo ko-kr Fri, 15 Aug 2025 00:00:00 +0000 https://gukin.dev/posts/read-heavy-pagination-optimization/ Fri, 15 Aug 2025 00:00:00 +0000 https://gukin.dev/posts/read-heavy-pagination-optimization/ <h2 id="요약">요약</h2> <ul> <li><strong>정규화 쿼리(집계 + 정렬)</strong> → 풀스캔 + filesort로 <strong>~17초</strong> 소요.</li> <li><strong>역정규화 + 정렬 포함 인덱스</strong> → <strong>~227ms</strong> (약 76배 향상).</li> <li><strong>OFFSET 페이지네이션</strong> → 인덱스 순차 스캔 시작 → 임계점에서 Table Scan + Filesort로 전환 → 이후 응답시간 급등.</li> <li><strong>전환 전 일정한 속도</strong>는 InnoDB 버퍼 풀/캐시 히트율 덕분.</li> <li><strong>Keyset(Seek) 페이지네이션</strong> → 깊은 페이지에서도 일정 성능 (421ms → 31ms, 92.6% 단축).</li> <li><strong>인덱스 설계</strong>는 핫 트래픽 패턴(브랜드 + 인기순/최신순/최저가순)에 맞춘 3개의 복합 인덱스 유지가 가성비 최적. <ul> <li>설계 원칙: 필터 선두 → 정렬키 → tie-breaker(id)</li> </ul> </li> <li><strong>캐시(Cache-Aside)</strong> 적용 시 200RPS에서도 DB I/O 부하 없이 ms 단위 응답 가능. <ul> <li>단, TTL·Evict 정책·실시간성 요구사항·정합성 유지·스탬피드 방지 등 고려 필수.</li> </ul> </li> <li>결론: <strong>정규화/역정규화 → 인덱스 설계 → 페이지네이션 전략 → 캐싱</strong>이 단계적으로 맞물려 성능을 좌우함.</li> </ul> <h2 id="문제-정의와-가설">문제 정의와 가설</h2> <p>웹 서비스에서는 쓰기 보다 <strong>읽기 트래픽이 압도적으로 많다</strong>는 글을 읽거나 실제로 경험해봤을 것이다.</p>