[CS 지식] 페이지네이션(Pagination) 구현 Offset 기반 vs Cursor 기반

📝Offset 기반 Pagination

LIMIT과 OFFSET을 사용하여 특정 위치부터 데이터 가져옵니다

 

 

❤️장점

-- 41~60번째 글
SELECT *
FROM posts
WHERE status = 'PUBLISHED'
ORDER BY created_at DESC
LIMIT 20 OFFSET 40;

1. 구현이 엄청 간단하고 쿼리가 직관적입니다.

 

⚠️단점

1. 중간에 데이터가 삽입/삭제되면 페이지 불일치 가능성 존재
2. Offset 기반은 건너뛰는 비용 문제가 있는데 OFFSET 40일 때 0~40번째 데이터를 읽은 후 건너뛰어야하기 때문에 OFFSET이 커질수록 속도가 매우 느려지게 됩니다. 그렇기 때문에 많은 데이터가 있을 때 페이지를 뒤로갈수록 느려지게 됩니다. (검색 결과가 수천~1만건 정도까지는 Offset 기반으로 처리가 가능)

 

🔎사용

블로그, 게시판, 단순 목록 페이지에 사용

 

 

📝Offset 기반 Pagination (대량 데이터) 처리

앵커

대량 데이터에서 특정 페이지로 점프하기 위한 보조 인덱스를 두는 방식입니다.

일정 간격마다 앵커포인트를 줘서 (예를 들면 10페이지마다 인덱스) 해당페이지로 이동 후에 OFFSET으로 이동합니다.

 

정렬이나 필터조건에 따라 순서가 달라지기 때문에 이러한 조건들도 테이블에 따로 저장해야합니다.

 

 

스냅샷

앵커의 경우 앵커의 포인트를 저장하지만 스냅샷의 경우 모든 페이지의 인덱스를 저장합니다.

 

 

위 방법도 Trade Off가 있습니다. 예를 들면 데이터가 INSERT나 DELETE가 될 때마다 인덱스를 가진 테이블이 계속 최신화가 되어야하기 때문에 계속적인 테이블 관리가 되어야 최신화가 됩니다. 그로 인해 여러가지 이슈가 있기 때문에 운영적인 걸로 해결하는 경우가 많습니다. 예) 50페이지까지 제한 / 3개월 데이터만 보여주기

 

 

 

📝Cursor 기반 Pagination

마지막 조회한 레코드의 고유 키(또는 정렬 기준 값)를 기억하고, 그 이후 데이터를 가져옵니다.

요즘 추세는 무한스크롤이 많기 때문에 커서기반으로 많이 사용합니다

 

 

❤️장점

SELECT * FROM articles 
WHERE created_at < '2025-08-15 10:00:00'
ORDER BY created_at DESC LIMIT 10;

1. OFFSET을 사용하지 않기 때문에 성능이 좋습니다.
2. 무한스크롤에 가장 적합합니다.

 

⚠️단점

1. 필요한 구간만 딱 조회하기 때문에 페이지 번호로 점프하기 어렵습니다.

 

🔎사용

트위터 타임라인, 인스타그램 피드, 실시간 스트리밍 목록

 

 

🔗 출처 및 참고

https://maxzidell.medium.com/%ED%8E%98%EC%9D%B4%EC%A7%80%EB%84%A4%EC%9D%B4%EC%85%98-%EB%A6%AC%EB%94%94%EC%9E%90%EC%9D%B8-cb42badc6af4