답변.

페이지 매김(페이징)은 과도한 서버 및 애플리케이션 부하 없이 대량의 SELECT 결과를 처리합니다. 주요 접근 방법:

LIMIT/OFFSET — 편리하지만 큰 OFFSET에서는 비효율적입니다.
Keyset pagination (Seek method) — 고유하거나 정렬 가능한 필드(예: id 또는 timestamp) 값을 통해, '깊은' 탐색에서 훨씬 더 효율적입니다.

예시 (LIMIT/OFFSET)

SELECT * FROM Orders
ORDER BY OrderID
LIMIT 100 OFFSET 1000;

이 쿼리는 1011–1110 번째 레코드를 반환합니다. 그러나 OFFSET은 서버가 여전히 첫 1000줄을 다시 정렬하고 пропустить 해야 하므로 깊은 페이지 매김에서는 느려집니다.

예시 (Keyset/Seek method)

SELECT * FROM Orders
WHERE OrderID > 1110
ORDER BY OrderID
LIMIT 100;

이 쿼리는 OFFSET 계산에 자원을 소모하지 않고 신속하게 다음 페이지를 찾습니다. 특히 OrderID에 인덱스가 있을 때 훨씬 더 효과적입니다.

트릭 질문.

트릭: “왜 LIMIT/OFFSET을 통한 페이지 매김이 대량 데이터에서 잘 작동하지 않으며 이를 개선할 수 있는 방법은 무엇인가요?”

답변: 문제는 OFFSET이 서버에게 모든 이전 행을 스캔하고 정렬하도록 요구하기 때문에, 페이지가 더 깊어질수록 느려집니다. 최적화는 keyset/seek paging으로 전환하여 이전 페이지의 마지막 레코드 키를 기반으로 선택하는 것입니다.

-- 키를 기반으로 다음 페이지 가져오기
SELECT * FROM Orders WHERE OrderID > @LastOrderID ORDER BY OrderID LIMIT 100;

이 주제의 세부사항을 몰라 발생한 실제 오류 사례.

이야기

프로젝트: 마켓플레이스, 5년 간의 주문 데이터(5000만 행)

오류: 오래된 사용자 주문에 대해 OFFSET을 사용하여 페이지 매김을 하였습니다. OFFSET > 100만 쿼리는 30–60초 만에 실행되기 시작했습니다. 이는 보고서와 API 인터페이스에 영향을 미쳤으며, 이로 인해 서버 CPU가 과부하되고 대기 시간이 증가했습니다.

이야기

프로젝트: 기업 CRM, 고객에 대한 보고서.

오류: 페이지 매김에서 정렬 순서를 고려하지 않고 인덱스를 사용하지 않았습니다. 성능과 샘플 무결성이 떨어졌으며, 사용자는 테이블 변경 시 서로 다른 페이지에서 동일한 행을 받았습니다.

이야기

프로젝트: 금융 플랫폼, 대시보드.

오류: 복잡한 페이지 매김이 바인드 변수가 없는 동적 SQL로 생성되어 SQL 주입 및 데이터 간 페이지 간 트랜잭션 유지와 관련된 문제를 초래했습니다.

대용량 SQL 데이터의 페이지 매김(페이징)을 구현하여 데이터 양과 관계없이 높은 성능을 보장하는 방법은 무엇인가요?

답변.

트릭 질문.

이 주제의 세부사항을 몰라 발생한 실제 오류 사례.