taeknology/notes

[MySQL] 페이지네이션 OFFSET vs 키셋: 응답 시간 비교와 선택 기준

개요

한 줄 요약: 같은 데이터·인덱스에서 측정하면 OFFSET-LIMIT 는 위치에 비례해 선형으로 느려지고 키셋은 위치와 무관하게 상수 시간임. 선택 기준은 UI 가 랜덤 점프를 요구하느냐 / 순차 다음을 요구하느냐로 갈림.

이 글은 두 페이지네이션 방식의 결정 가이드임. 각 방식의 메커니즘·작성 함정은 별도 글에서 다룸.

항목내용
검증 버전MySQL 8.4.8
데이터1,280,000행, payload 100바이트, (created_at, id) 보조 인덱스

결론

응답 시간 비교 — PK 단일 정렬

같은 위치에서 두 방식의 응답 시간 차이가 깊은 페이지 기준 수백 배 까지 벌어짐.

위치 (OFFSET / pivot id)OFFSET-LIMIT 20키셋 id > pivot LIMIT 20
00.06 ms~ 0.5 ms
1,0001.91 ms1.5 ms
100,00071.6 ms2.86 ms
500,000147 ms8.42 ms
1,000,000466 ms0.84~1.25 ms

두 컬럼 모두 warm 반복 측정값. OFFSET 1M 의 cold 첫 호출은 335 ms / 키셋 1M 의 cold 첫 호출은 7.64 ms 가 잡혔으나 정상 상태 비교를 위해 warm 으로 통일. 키셋 측 1M 이 500k 보다 작아 보이는 건 측정 시점 버퍼풀 워밍 차이로, 위치 무관 1 ms 안팎이 본질임 — 자세한 측정 컨텍스트는 mysql-pagination-keyset 참조.

선택 기준

상황권장
무한 스크롤 / “다음” 버튼만 있는 UI키셋 (cursor)
깊은 페이지로 점프(?page=12345) 가 필요한 관리자 도구OFFSET 허용 + 상한·인덱스 점검
정렬키가 PK 단일 컬럼키셋이 가장 단순
정렬키가 (created_at, id) 같은 복합 비유일 키키셋 OR 형태 + 커버링 인덱스 필수
랜덤 액세스가 필요한 보고서·CSV export둘 다 비효율 — 범위 기반 WHERE 분할

운영 체크리스트

  • 깊은 OFFSET 이 절대 안 들어오게 막을 수 있으면 가장 좋음 — UI 에서 “다음” 만 노출하거나, API 에서 OFFSET 상한(예: 10,000)을 둠.
  • 키셋을 도입할 땐 EXPLAIN ANALYZE 로 range scan 여부와 PK 룩업 발생 여부를 같이 점검. 두 함정의 상세는 mysql-pagination-keyset 참조.
  • 새 화면을 설계할 때부터 둘 중 하나로 결정. 같은 화면에서 두 방식을 섞으면 인덱스 전략과 캐시 키가 같이 흔들림.

상세

두 방식의 비용 모델 한 줄 요약

방식비용 모델위치별 비용
OFFSET-LIMITM + N 행을 만든 뒤 앞 M 행을 폐기위치에 선형
키셋(cursor)이전 페이지의 마지막 키로 시작점만 찾고 N 행 읽음위치와 무관 상수

OFFSET-LIMIT 의 EXPLAIN 출력과 보조 인덱스가 무력해지는 함정은 mysql-pagination-offset-cost 의 상세 섹션에서, 키셋의 단일/복합 정렬 작성 규칙은 mysql-pagination-keyset 의 상세 섹션에서 다룸.

측정 절차

위 표의 모든 응답 시간은 같은 테이블·같은 세션에서 캡처함. 테이블 DDL·데이터 생성·각 시나리오 EXPLAIN 출력은 두 개별 글에 동일하게 들어 있음. 본 글은 비교 표로 의사결정만 빠르게 끝낼 수 있도록 측정 절차 자체는 반복하지 않음.

MySQL 8.4.8 에서 직접 확인 — actual time 의 두 번째 값(누적)을 비교 기준으로 사용.

참고

관련 글