📃 페이지네이션 가이드 | 커서로 바꿔야 할까?

총 행 수

한 페이지에 담을 행 수

살펴볼 페이지 번호

읽는 중 앞쪽에 끼어든 행 수 (선택)

테이블 이름

정렬 기준 컬럼 (고유해야 함)

그 페이지를 읽을 때 오프셋 방식이 훑는 행 수

총 페이지 수 (올림)-

마지막 페이지의 오프셋-

그 페이지에서 커서 방식이 훑는 행 수-

끝까지 넘길 때 오프셋 누적-

끝까지 넘길 때 커서 누적-

누적 비교 (소수 2자리)-

끼어든 행 때문에 생기는 중복-

같은 페이지를 읽는 세 가지 질의

세 방식의 차이

방식	깊은 페이지	읽는 중 자료가 바뀌면	임의 페이지로 바로 가기	전체 개수
오프셋	건너뛸 행을 모두 훑어 느려짐	중복·누락이 생김	가능	따로 세면 알 수 있음
페이지 번호	오프셋과 같음 (번호를 오프셋으로 바꿔 쓰므로)	중복·누락이 생김	가능	따로 세면 알 수 있음
커서 (키셋)	마지막으로 읽은 값부터 찾아 페이지 크기만 읽음	중복·누락이 생기지 않음	불가 — 앞 페이지를 거쳐야 함	따로 세는 질의가 필요함

페이지 크기에 공인된 권장값은 없습니다. 응답 크기와 요청 횟수를 어떻게 나누고 싶은지에 따라 달라지므로 직접 넣어 결과를 비교하세요. 훑는 행 수는 정렬 컬럼에 인덱스가 있고 그 순서로 읽는다는 가정에서 센 값이고, 실제 실행계획은 데이터와 통계에 따라 달라집니다.

도구 설명

총 행 수와 페이지 크기, 살펴볼 페이지 번호를 넣으면 오프셋 방식이 그 페이지를 읽을 때 몇 행을 훑고 몇 행을 버리는지 계산합니다. 오프셋은 건너뛸 행을 세기 위해 그 행들을 실제로 읽기 때문에, 느려지는 원인은 자료량이 아니라 페이지 깊이입니다. 같은 페이지를 커서 방식으로 읽으면 몇 행을 읽는지도 함께 내놓아 두 방식의 차이를 숫자로 볼 수 있습니다.

두 번째로 계산하는 것은 중복과 누락입니다. 목록을 읽는 중에 앞쪽에 행이 끼어들면 뒤 페이지의 경계가 밀려서 이미 본 행이 다시 나옵니다. 끼어든 행 수를 넣으면 중복될 행 수를 세어 주고, 커서 방식에서는 이 영향이 없는 이유도 함께 적습니다. 끝까지 넘길 때 두 방식이 누적으로 훑는 행 수와 그 비율도 계산합니다.

페이지 크기에 공인된 권장값은 없으므로 수치를 제시하지 않습니다. 훑는 행 수는 정렬 컬럼에 인덱스가 있고 그 순서로 읽는다는 가정에서 센 값이고, 실제 실행계획은 자료와 통계에 따라 달라집니다. 이 도구는 응답 시간을 예측하지 않고 어느 방식이 옳다고 판정하지도 않습니다.

자주 묻는 질문

오프셋은 왜 뒤 페이지에서 느려지나요?

건너뛸 행 수를 세려면 그 행들을 실제로 읽어야 합니다. 1000번째 페이지를 읽으려면 앞의 행을 모두 읽고 버린 뒤 마지막 한 페이지만 돌려줍니다. 버리는 양이 페이지 깊이에 비례해 늘어나므로 뒤로 갈수록 느려집니다.

커서 방식은 왜 중복이 없나요?

몇 번째부터가 아니라 마지막으로 읽은 값보다 뒤를 찾기 때문입니다. 앞쪽에 행이 끼어들거나 지워져도 기준값이 그대로라 경계가 밀리지 않습니다. 대신 정렬 기준이 고유해야 하고 임의 페이지로 바로 갈 수 없습니다.

이 도구가 하지 않는 것은 무엇인가요?

권장 페이지 크기 제시, 응답 시간 예측, 실행계획 해석은 하지 않습니다. 훑는 행 수와 중복·누락 행 수를 계산하고 질의 예시를 만듭니다.

📃API 페이지네이션 방식 선택 가이드

세 방식의 차이

관련된 도구

REST API 네이밍 검사기

REST 리소스 URL 설계 가이드

도구 설명

자주 묻는 질문

세 방식의 차이

관련된 도구

REST API 네이밍 검사기

REST 리소스 URL 설계 가이드

도구 설명

자주 묻는 질문

같은 카테고리 도구