PageNation: 검색 결과에서 데이터를 나누어 필요한 만큼만 가져오는 방법입니다.
대표적인 두 방식은 offset-limit 방식과 cursor 방식이 있습니다.
Offset-Limit 방식
데이터를 일정 개수씩 쪼개서 가져오는 방식입니다.
offset 값이 증가하면서 이전에 가져온 데이터를 넘어가고, 각 쿼리는 범위에 맞는 데이터를 반환합니다.
그러나 데이터의 양이 많을 때 offset 값이 커지면 문제가 발생하는데,
offset 값에 해당하는 레코드를 건너뛰기 위해 모든 데이터를 스캔하느냐 시간이 많이 소모됩니다.
ex)
select * from dd limit 40 offset 0;
select * from dd limit 40 offset 40;
select * from dd limit 40 offset 80;
Cursor 방식
어떠한 레코드를 가르키는 포인터를 뜻하며, 이 cursor가 가리키를 레코드부터 일정 개수만큼 데이터를 가져옵니다.
where id < xx 처럼 조건을 설정하여 해당 ID보다 큰 값부터 데이터를 가져오며, 이때 id는 고유한 값입니다.
이렇게 하면, 이전의 데이터를 순회하지 않고 이후의 데이터를 바로 가져옵니다.
ex)
SELECT id FROM dd ORDER BY id DESC LIMIT 5
결론
제가 이해한 바로는
cursor은 순서 기반으로 값을 찍어서 바로 가져오는 것이고
offset은 데이터를 하나하나 세는 것입니다.
지금 여러 목록 페이지들은 데이터를 한번에 불러오는데
많은 데이터를 불러오는 목록 페이지들에 pageNation을 적용하면 좋을 것 같습니다.
--- 2026.01.06 업데이트 ---
Cursor 방식을 유의미하게 사용하려면 반드시 인덱싱이 걸려있어야 한다.
ex)
SELECT *
FROM DOCMST
WHERE DOCSEQ < :last_docseq
ORDER BY DOCSEQ DESC
LIMIT 30;
위 쿼리를 예시로 들어보자.
DOCSEQ에 인덱싱을 걸지 않으면,
- DB는 DOCMST 전체 스캔
- 조건 DOCSEQ < ? 전부 검사
- 정렬(ORDER BY DOCSEQ DESC) 수행
- 그중 30개 반환
>> 데이터가 1만 → 10만 → 100만 늘수록 선형으로 느려짐
DOCSEQ 인덱싱이 되어있다면,
- 인덱스에서 :last_docseq 바로 탐색
- 인덱스 leaf에서 30개만 읽음
- 정렬 필요 없음 (인덱스 순서 그대로)
>> 페이지가 몇 번째든 속도 거의 동일
------
'CS' 카테고리의 다른 글
| 뒤로 가기 시 데이터 초기화 문제 해결 방법(BFCache와 PageShow) (0) | 2025.06.20 |
|---|---|
| 프로세스, RESTful API, Spring bean container 생성과 종료 (0) | 2024.06.18 |