비교할 문제
OFFSET 페이지네이션에서 확인할 질문은 깊은 OFFSET과 keyset pagination의 지연·정합성 차이는 무엇인가입니다. 정렬 key, tie-breaker와 삭제·삽입 중 page 중복 허용 범위를 API 계약에 명시합니다. 결과값, 순서, 오류 처리와 부수 효과가 다르면 같은 성능 비교가 아닙니다. 먼저 두 후보가 같은 일을 하는지 작은 입력으로 확인합니다.
원인 분석과 재현
큰 OFFSET은 앞 row를 찾아 버리는 비용이 커지고 동시 변경에서 중복·누락이 생길 수 있어 안정 정렬과 keyset cursor를 검토해야 합니다.
첫 page·10만 번째 page, 동시 insert·delete, 복합 정렬과 index 유무에서 examined row와 시간을 봅니다. runtime version, 운영체제, CPU와 memory 제한도 결과와 함께 기록합니다. 이 예제의 plan과 문법은 MariaDB 기준이며 다른 DB 제품의 결과로 일반화하지 않습니다.
비교 질문은 깊은 OFFSET과 keyset pagination의 지연·정합성 차이는 무엇인가입니다.
| 후보 | 유리한 조건 | 함께 치르는 비용 |
|---|---|---|
| LIMIT/OFFSET | 임의 page 번호 이동 | 깊은 page까지 앞 row를 건너뛰는 비용과 변경 중 중복·누락 |
| keyset/cursor | 다음·이전 연속 탐색 | 안정된 unique 정렬 key와 opaque cursor 필요 |
ANALYZE FORMAT=JSON SELECT id, created_at FROM orders ORDER BY id DESC LIMIT 50 OFFSET 100000;
ANALYZE FORMAT=JSON SELECT id, created_at FROM orders WHERE id < 900000 ORDER BY id DESC LIMIT 50;
-- keyset 후보는 임의 page 이동 대신 마지막 id를 cursor로 전달하는 API 계약이 필요합니다.
해결 방안과 판정
warm-up과 측정 구간을 나누고 여러 번 반복합니다. 서비스 지연은 median과 p95를, 처리량 비교는 단위 시간당 완료 수와 오류율을 함께 기록합니다. CPU time, allocation, RSS·heap, GC, I/O 중 이 작업에 직접 관련된 지표만 선택합니다. keyset은 OFFSET의 빠른 문법 대체가 아니라 pagination UX와 API 계약 변경입니다. 임의 page 이동이 꼭 필요한지도 제품 요구에서 확인합니다.
차이가 반복 실행의 흔들림보다 작다면 더 단순하고 읽기 쉬운 구현을 선택합니다. 차이가 충분히 크더라도 실제 요청 전체의 지연과 자원 사용이 개선되는지 확인한 뒤 적용합니다.
공식 문서와 적용 범위
문서의 기본값과 동작은 version에 따라 달라질 수 있습니다. 현재 DB 제품과 version, schema·index·통계 상태, 데이터 분포와 동시 부하에서 다시 확인합니다.